Inquiries About The LibDom Library

 

Hello NetSurf team,

 

I am an undergrad student currently working on a project aiming to supplement NetSurf's javascript capabilities. I am still at a learning stage, so if the following doesn't make sense please try to bear with me.

 

I have been exploring the code of the netsurf project and the libdom library, and as such, I had a some questions:

 

1. What is the current status of the libdom project and who is in charge of it ?

 

2. I see that netsurf's core dom support is standing at Level 3 DOM, are there any plans for the libdom library to follow the W3C DOM4 recommendations ? and as such, by contributing to libdom should I try to stick to the Level 3 DOM spec or aim for the DOM4 specs ?

 

Thank you for your time,

Cheers.

 

-Pascal Archambault

Re: Text colour

Peter Slegg wrote:

> Hi,
>
> https://newsspaceflight.com/news-from-space-tech-expo/
>
> This page mostly show black text on a black background.
> Atari build 4350. Is it the same in other ports ?

Hi,

It's white on black on Unix/GTK. The design is pretty bad IMO,
even in Firefox it's not pretty.

--
caóc

Re: [Rpcemu] RPCEmu 0.9.0 — Networking issues

rpclog.txt:

localtime: 2018-05-30 18:14:11
   gmtime: 2018-05-30 17:14:11
RPCEmu 0.9.0 [INTERPRETER NO_DEBUG]
Build: 64-bit binary
Compiler: GCC version 7.3.0
OS: SysName = Linux
OS: Release = 4.15.0-22-generic
OS: Version = #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018
OS: Machine = x86_64
QT5: 5.9.5
Number of screens: 1
Primary screen: eDP-1
Information for screen: eDP-1
 Resolution: 1920 x 1080
 Colour depth: 24
Working Directory: /home/davidg/rpcemu-ro4.02
config_load: bridgename = "rpcemu"
config_load: cdrom_enabled = "1"
config_load: cdrom_iso = ""
config_load: cdrom_type = "0"
config_load: cpu_idle = "0"
config_load: ipaddress = "172.31.0.1"
config_load: macaddress = ""
config_load: mem_size = "32"
config_load: model = "RPC610"
config_load: mouse_following = "1"
config_load: mouse_twobutton = "0"
config_load: network_type = "iptunnelling"
config_load: refresh_rate = "60"
config_load: sound_enabled = "0"
config_load: stretch_mode = "1"
config_load: username = ""
config_load: vram_size = "2"
romload: Loaded 'ROM402' 4194304 bytes
romload: Total ROM size 4 MB
romload: ROM patch applied: 8MB VRAM RISC OS 4.02
plt_sound: qt5 Audio Device: alsa_output.pci-0000_00_1f.3.analog-stereo
plt_sound: qt5 Audio Codecs Supported: 1
0: audio/pcm
plt_sound: qt5 Audio SampleRates Supported: 5
0: 8000
1: 11025
2: 22050
3: 44100
4: 48000
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
RPCEmu: Machine reset
Networking: Dropping runtime privileges back to 'davidg'
RPCEmu: Machine reset complete
HostFS: Registration request version 3 accepted

On 30/05/18 21:40, Peter Howkins wrote:
> On Wed, 30 May 2018 at 16:30, David Gee <dr.david.gee@outlook.com> wrote:
>
>> I'm trying to get networking working on RPCEmu 0.9.0, running under
>> Ubuntu 18.04/Gnome. I've followed the steps given for IP tunnelling, and
>> everything responds correctly, except for the last phase: I can ping the
>> router (192.168.0.1) but if I try 'ping www.marutan.net', I get 'unknown
>> host www.marutan.net'.
>> I've tried this with the name server set to 192.169.0.1
> I presume you meant to type 192.168.0.1 here.
>
>> and I've also
>> tried setting this to 8.8.8.8 (Google public DNS), but that makes no
>> difference, even though I can ping 8.8.8.8.
> That you can ping by IP address proves your networking is up, but the lack
> of name resolution means that DNS is failing.
>
> Can you post your rpclog.txt file please, and I'll try to reproduce your setup.
>
> Peter
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

--
David Gee
dr.david.gee@outlook.com

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

There seems to be a lot of threads regarding this issue.

https://ubuntuforums.org/archive/index.php/t-1848739.html (someone suggests turning off 'place windows' in CCSM although that was for Unity on Gentoo)

Also this: https://stackoverflow.com/questions/34870496/application-viewer-setfullscreen-function-not-hiding-ubuntu-sidebar (might also be a starting point for a fix in RPCEmu itself but note the last comment)

Regards,

James

On Wed, May 30, 2018 at 5:32 PM, Matthew Howkins <rpcemu-list@howkins.me.uk> wrote:

On 29 May 2018 at 18:42, David Gee <dr.david.gee@outlook.com> wrote:

I notice Steve Fryatt's issue with the full screen mode on the new
RPCEmu. I've encountered the same issue. (I've just joined the list, and
have looked at the archive, but can't reply to the earlier email—sorry.)

In my case it was with Ubuntu 16.04 and the MATE desktop, not Unity. In
my case it only occurred if the resolution was other than 800x600; at
800x600 it would go into full screen correctly, and I could then change
the resolution to whatever I wanted (in this case, 1360x768). But if the
resolution was 1360x768 to start with, I got exactly the issue Steve
described. HP laptop withg 1366x768 screen.

I've also tried running RPCEmu 0.9.0 on Ubuntu 18.04 with Gnome, and on
that system full screen mode is fine (and Gnome can detect a "middle
click" on the trackpad, which helps a lot). HP laptop with 1920x1080 screen.

In the meantime, you should be able to ALT-drag the rogue window around,
but I admit I haven't tried this...

This sounds like it could be another distro/Window Manager problem again:

I've found at bug at https://bugs.launchpad.net/ubuntu-mate/+bug/1597064

This discusses a problem where a Java application won't go full screen properly in Ubuntu 16.04 with MATE (or according to the thread any Window Manager).

It does include a workaround, and you could try this.

Matthew

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Text colour

In message <000cb429.01e9b4902cf2@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>Hi,
>
>https://newsspaceflight.com/news-from-space-tech-expo/
>
>This page mostly show black text on a black background.
>Atari build 4350. Is it the same in other ports ?

The text appears white on a black background in RISC OS build 4350.

Dave

Re: Text colour

In RISC OS build #4350 I see mainly white text on a black background.


In article <000cb429.01e9b4902cf2@smtp.freeola.net>,
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Hi,

> https://newsspaceflight.com/news-from-space-tech-expo/

> This page mostly show black text on a black background.
> Atari build 4350. Is it the same in other ports ?


> Peter

--
_____________________________________________________________________

Brian Jordan
RISC OS 5.23 on Raspberry Pi
_____________________________________________________________________

Text colour

Hi,

https://newsspaceflight.com/news-from-space-tech-expo/

This page mostly show black text on a black background.
Atari build 4350. Is it the same in other ports ?


Peter

Re: [Rpcemu] RPCEmu 0.9.0 — Networking issues

On Wed, 30 May 2018 at 16:30, David Gee <dr.david.gee@outlook.com> wrote:

> I'm trying to get networking working on RPCEmu 0.9.0, running under
> Ubuntu 18.04/Gnome. I've followed the steps given for IP tunnelling, and
> everything responds correctly, except for the last phase: I can ping the
> router (192.168.0.1) but if I try 'ping www.marutan.net', I get 'unknown
> host www.marutan.net'.

> I've tried this with the name server set to 192.169.0.1

I presume you meant to type 192.168.0.1 here.

> and I've also
> tried setting this to 8.8.8.8 (Google public DNS), but that makes no
> difference, even though I can ping 8.8.8.8.

That you can ping by IP address proves your networking is up, but the lack
of name resolution means that DNS is failing.

Can you post your rpclog.txt file please, and I'll try to reproduce your setup.

Peter

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

On 29 May 2018 at 18:42, David Gee <dr.david.gee@outlook.com> wrote:

I notice Steve Fryatt's issue with the full screen mode on the new
RPCEmu. I've encountered the same issue. (I've just joined the list, and
have looked at the archive, but can't reply to the earlier email—sorry.)

In my case it was with Ubuntu 16.04 and the MATE desktop, not Unity. In
my case it only occurred if the resolution was other than 800x600; at
800x600 it would go into full screen correctly, and I could then change
the resolution to whatever I wanted (in this case, 1360x768). But if the
resolution was 1360x768 to start with, I got exactly the issue Steve
described. HP laptop withg 1366x768 screen.

I've also tried running RPCEmu 0.9.0 on Ubuntu 18.04 with Gnome, and on
that system full screen mode is fine (and Gnome can detect a "middle
click" on the trackpad, which helps a lot). HP laptop with 1920x1080 screen.

In the meantime, you should be able to ALT-drag the rogue window around,
but I admit I haven't tried this...

This sounds like it could be another distro/Window Manager problem again:

I've found at bug at https://bugs.launchpad.net/ubuntu-mate/+bug/1597064

This discusses a problem where a Java application won't go full screen properly in Ubuntu 16.04 with MATE (or according to the thread any Window Manager).

It does include a workaround, and you could try this.

Matthew

[Rpcemu] RPCEmu 0.9.0 — Networking issues

I'm trying to get networking working on RPCEmu 0.9.0, running under
Ubuntu 18.04/Gnome. I've followed the steps given for IP tunnelling, and
everything responds correctly, except for the last phase: I can ping the
router (192.168.0.1) but if I try 'ping www.marutan.net', I get 'unknown
host www.marutan.net'.

I've tried this with the name server set to 192.169.0.1, and I've also
tried setting this to 8.8.8.8 (Google public DNS), but that makes no
difference, even though I can ping 8.8.8.8.

Any ideas?

--
David Gee
dr.david.gee@outlook.com

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.0

I notice Steve Fryatt's issue with the full screen mode on the new
RPCEmu. I've encountered the same issue. (I've just joined the list, and
have looked at the archive, but can't reply to the earlier email—sorry.)

In my case it was with Ubuntu 16.04 and the MATE desktop, not Unity. In
my case it only occurred if the resolution was other than 800x600; at
800x600 it would go into full screen correctly, and I could then change
the resolution to whatever I wanted (in this case, 1360x768). But if the
resolution was 1360x768 to start with, I got exactly the issue Steve
described. HP laptop withg 1366x768 screen.

I've also tried running RPCEmu 0.9.0 on Ubuntu 18.04 with Gnome, and on
that system full screen mode is fine (and Gnome can detect a "middle
click" on the trackpad, which helps a lot). HP laptop with 1920x1080 screen.

In the meantime, you should be able to ALT-drag the rogue window around,
but I admit I haven't tried this...

--
David Gee
dr.david.gee@outlook.com

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

I don't think I can help with the window-manager or cpu_idle=1 issue (might be an IDE timing issue with the latter but that's just a guess).

With cpu_idle=0 AFAIK the emulator will consume 100% of one CPU core for the main thread.

You could try this source-code hack to reduce CPU usage (but it may cause the same problem as cpu_idle=1). I haven't tested it on Linux however.

In rpc-qt5.cpp between the lines 'elapsed_timer.start();' and '// Handle qt events and messages' replace the contents with:

    int sleep_countdown = 10 ; // Sleep 1ms every n times around the main loop
    int sleep_countdown_counter = sleep_countdown ;

    while (!quited) {
       
        // Time to sleep to reduce CPU usage?
        if ((sleep_countdown_counter--) == 0)
        {
            #if defined(Q_OS_WIN32)
            Sleep(1) ;
           

[Rpcemu] RPCEMU edge case use - CCl4

I know I'm a very much edge case user of rpcemu (probably).

I use rpcemu to run "headless" fish.ccl4.org, which is a viewdata bulletin
board - it used to run on an A5000, orginally on a Demon employee's
baseband line and various DSL lines since. The A5000 packed in a bit ago
(though I still have it somewhere).

For various reasons it now runs on a VM "somewhere" using rpcemu, with a
config of:

bridgename = br0
model = RPCSA
mouse_twobutton = 0
network_type = iptunnelling
mouse_following = 1
cdrom_type = 0
cdrom_enabled = 0
refresh_rate = 5
stretch_mode = 1
sound_enabled = 0
vram_size = 2
mem_size = 32
ipaddress = 172.31.0.1
cpu_idle = 1

With this it takes about 12% or less cpu on idle.

There is no window manager, just Xvnc.

I use hostfs, I haven't tried it recently but with cpu_idle=1 it quickly
resulted in corrupt .hdf images previously.

I tried the new version with the shift to Qt and it does seem slightly
confused with the lack of a window manager and the cpu has increased to
more like 16% or more on idle.

This is the interpreter, the recompiler has always taken lots more % when
I've tried it.

I've gone back to the "old" version, but any suggestions ? Can any simple
tweaks be made to cope with my usage ? I would very much prefer to not run
a window manager (even Matchbox) - VNC access is not the norm, but
occasionally neccessary for admin.

Running the old version is not a problem per se, but I would prefer to
keep uptodate if possible.

Thanks.

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

I may have a source-code modification to fix the accent/dead-key issue on Windows in a few days. Possibly Linux as well. I'm having to re-learn bits of C++ that I forgot many many years ago, hehe.

On Sat, May 26, 2018 at 8:15 AM, Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:

Hi Frank, holding Right Alt while pressing one of the other keys to get " ' ` ~ ^ does not produce output here unfortunately. Best regards, Jeroen

On 25-5-2018 22:26, Frank de Bruijn wrote:

In article <44d551e9-2603-0afa-2756-fab07cc33fca@home.nl>,
    Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:

Hi Frank, I've tried with different keyboard settings, but unfortunately
none of them is giving " at my end?

So AltGr didn't help? Not the same issue then.

I wonder what the devs make of these problems...

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Hi Frank, holding Right Alt while pressing one of the other keys to get
" ' ` ~ ^ does not produce output here unfortunately. Best regards, Jeroen


On 25-5-2018 22:26, Frank de Bruijn wrote:
> In article <44d551e9-2603-0afa-2756-fab07cc33fca@home.nl>,
> Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:
>> Hi Frank, I've tried with different keyboard settings, but unfortunately
>> none of them is giving " at my end?
> So AltGr didn't help? Not the same issue then.
>
> I wonder what the devs make of these problems...
>
> Regards,
> Frank
>
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>


---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <44d551e9-2603-0afa-2756-fab07cc33fca@home.nl>,
Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:
> Hi Frank, I've tried with different keyboard settings, but unfortunately
> none of them is giving " at my end?

So AltGr didn't help? Not the same issue then.

I wonder what the devs make of these problems...

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Hi Frank, I've tried with different keyboard settings, but unfortunately
none of them is giving " at my end?

Best regards,
Jeroen

On 25-5-2018 16:19, Frank de Bruijn wrote:
> In article <b34012e0-124c-bb10-02db-90fd254fa737@home.nl>,
> Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:
>> So, work around is available for me it looks like though not ideal :-)
>> Put RISCOS !Boot -> Keyboard to USA and when using RPCEmu put Windows
>> keyboard to United Kingdom temporarily.
> Not ideal, no. But you have a workaround at least. Did you check whether
> holding down the AltGr key made any difference? It would be good to know
> whether this was in any way related to what I'm seeing here.
>
> Regards,
> Frank
>
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>


---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <CAFWmK8xDXTm5o419BezW2F2Y35Tt9-4sRG+v6TXPjKtUB1CMVg@mail.gmail.com>,
J Percival <perciv.js@gmail.com> wrote:
> Okay, I get what you mean by accent keys now - so trying to produce a
> normal single quote for example in RPCEmu and having to hold down Alt-Gr?
> But it works fine outside of the emulator? That's strange.
> I had a look at RPCEmu's keyboard handling code a bit. It uses
> scancodes/keycodes and its own translation tables (explains why setting US
> layout in Windows didn't make any difference). The codes on Linux (X11)
> aren't raw scancodes apparantly as they can be altered by the host to take
> account of different keyboard layouts, but if this is sometimes a problem
> on Windows as well, then that's probably not relevant. I don't know why,
> say, a single quote would be treated as such in the host but as a dead key
> by RPCEmu but it could be a Qt bug. Input-handling doesn't seem to be one
> of its strong-points. Did you have the same problem in 0.8.15?

No, 0.8.15 was fine. Qt bug is definitely a possibility.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <b34012e0-124c-bb10-02db-90fd254fa737@home.nl>,
Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:
> So, work around is available for me it looks like though not ideal :-)
> Put RISCOS !Boot -> Keyboard to USA and when using RPCEmu put Windows
> keyboard to United Kingdom temporarily.

Not ideal, no. But you have a workaround at least. Did you check whether
holding down the AltGr key made any difference? It would be good to know
whether this was in any way related to what I'm seeing here.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Hi Jeroen. As I understand it, USA-International treats a number of keys (including single/double quotes) as the first part of a two-key combination to produce accented characters ( https://en.wikipedia.org/wiki/QWERTY#US-International ). You should be able to use the standard US keyboard layout in Windows instead of the UK one if you want - I think it's just the special handling of " ' ` ~ ^ in US-International that's the problem (and maybe some others). This should be possible to fix in RPCEmu itself in a later version so that all common keyboard layouts will work properly - a google search turned up a bunch of people with the same problem and there's a few solutions. Glad you got it working anyway. :)

Regards,

James

On Fri, May 25, 2018 at 2:29 PM, Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:

Hi,

Thank you Frank and J for the info provided so far! I was referring to the actual quotes key on a US keyboard, not accented characters I think. Apologies, if I didn't make that clear. On a US keyboard it's the key left from the Enter key and either used to put text between quotes, like this ' example' or (with Shift held down) "example", or in quite a few games as the up or forward key for player control (and that's why in !Hopper I could not move the frog upwards on the screen, only sideways).

J's response about Windows keyboard settings triggered me to try the following. Here in NL I use as Windows keyboard: USA (International). But I have added now under Windows the following keyboard as well: United Kingdom. When selecting the latter keyboard and trying the quotes key again in RPCEmu it's now being picked up. In !Edit it prints ' and (when Shift is held down) " on screen and in !Hopper the frog is moved upwards on the screen. When using this keyboard under Windows however then the quote key is giving me ' and (with Shift held down) @ instead of ".

So, work around is available for me it looks like though not ideal :-) Put RISCOS !Boot -> Keyboard to USA and when using RPCEmu put Windows keyboard to United Kingdom temporarily.

Hope this makes it a little bit clearer on what I'm experiencing!

Best regards,
Jeroen

On 25-5-2018 11:15, J Percival wrote:

Okay, I get what you mean by accent keys now - so trying to produce a normal single quote for example in RPCEmu and having to hold down Alt-Gr? But it works fine outside of the emulator? That's strange.

I had a look at RPCEmu's keyboard handling code a bit. It uses scancodes/keycodes and its own translation tables (explains why setting US layout in Windows didn't make any difference). The codes on Linux (X11) aren't raw scancodes apparantly as they can be altered by the host to take account of different keyboard layouts, but if this is sometimes a problem on Windows as well, then that's probably not relevant. I don't know why, say, a single quote would be treated as such in the host but as a dead key by RPCEmu but it could be a Qt bug. Input-handling doesn't seem to be one of its strong-points. Did you have the same problem in 0.8.15?

Regards,

James

On Fri, May 25, 2018 at 7:42 AM, Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:

In article <CAFWmK8yBw+vMAZjrVbQKtP+vjSK3wupnMDVQ5abCuN4mzV2=0w@mail.gmail.com>,
   J Percival <perciv.js@gmail.com> wrote:
> Hi Frank. My response was to Jeroen's e-mail. I assume he was talking about
> the actual quotes key on a US keyboard, rather than anything related to
> accented characters.

He wrote about the " and ' keys, which are essentially accent keys. He
also wrote '...pressing the key does not generate output.' which is the
same thing that's happening here when any of the accent keys are pressed
without AltGr. That's why I replied to him, suggesting he'd try the
AltGr route. As he hasn't responded yet, we can't be sure whether it is
the same issue or not yet, though.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

_______________________________________________  Rpcemu mailing list  Rpcemu@riscos.info  http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu  

Virusvrij. www.avast.com

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Hi,

Thank you Frank and J for the info provided so far! I was referring to the actual quotes key on a US keyboard, not accented characters I think. Apologies, if I didn't make that clear. On a US keyboard it's the key left from the Enter key and either used to put text between quotes, like this ' example' or (with Shift held down) "example", or in quite a few games as the up or forward key for player control (and that's why in !Hopper I could not move the frog upwards on the screen, only sideways).

J's response about Windows keyboard settings triggered me to try the following. Here in NL I use as Windows keyboard: USA (International). But I have added now under Windows the following keyboard as well: United Kingdom. When selecting the latter keyboard and trying the quotes key again in RPCEmu it's now being picked up. In !Edit it prints ' and (when Shift is held down) " on screen and in !Hopper the frog is moved upwards on the screen. When using this keyboard under Windows however then the quote key is giving me ' and (with Shift held down) @ instead of ".

So, work around is available for me it looks like though not ideal :-) Put RISCOS !Boot -> Keyboard to USA and when using RPCEmu put Windows keyboard to United Kingdom temporarily.

Hope this makes it a little bit clearer on what I'm experiencing!

Best regards,
Jeroen

On 25-5-2018 11:15, J Percival wrote:

Okay, I get what you mean by accent keys now - so trying to produce a normal single quote for example in RPCEmu and having to hold down Alt-Gr? But it works fine outside of the emulator? That's strange.

I had a look at RPCEmu's keyboard handling code a bit. It uses scancodes/keycodes and its own translation tables (explains why setting US layout in Windows didn't make any difference). The codes on Linux (X11) aren't raw scancodes apparantly as they can be altered by the host to take account of different keyboard layouts, but if this is sometimes a problem on Windows as well, then that's probably not relevant. I don't know why, say, a single quote would be treated as such in the host but as a dead key by RPCEmu but it could be a Qt bug. Input-handling doesn't seem to be one of its strong-points. Did you have the same problem in 0.8.15?

Regards,

James

On Fri, May 25, 2018 at 7:42 AM, Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:

In article <CAFWmK8yBw+vMAZjrVbQKtP+vjSK3wupnMDVQ5abCuN4mzV2=0w@mail.gmail.com>,
   J Percival <perciv.js@gmail.com> wrote:
> Hi Frank. My response was to Jeroen's e-mail. I assume he was talking about
> the actual quotes key on a US keyboard, rather than anything related to
> accented characters.

He wrote about the " and ' keys, which are essentially accent keys. He
also wrote '...pressing the key does not generate output.' which is the
same thing that's happening here when any of the accent keys are pressed
without AltGr. That's why I replied to him, suggesting he'd try the
AltGr route. As he hasn't responded yet, we can't be sure whether it is
the same issue or not yet, though.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

_______________________________________________  Rpcemu mailing list  Rpcemu@riscos.info  http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu  

Virusvrij. www.avast.com

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Okay, I get what you mean by accent keys now - so trying to produce a normal single quote for example in RPCEmu and having to hold down Alt-Gr? But it works fine outside of the emulator? That's strange.

I had a look at RPCEmu's keyboard handling code a bit. It uses scancodes/keycodes and its own translation tables (explains why setting US layout in Windows didn't make any difference). The codes on Linux (X11) aren't raw scancodes apparantly as they can be altered by the host to take account of different keyboard layouts, but if this is sometimes a problem on Windows as well, then that's probably not relevant. I don't know why, say, a single quote would be treated as such in the host but as a dead key by RPCEmu but it could be a Qt bug. Input-handling doesn't seem to be one of its strong-points. Did you have the same problem in 0.8.15?

Regards,

James

On Fri, May 25, 2018 at 7:42 AM, Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:

In article <CAFWmK8yBw+vMAZjrVbQKtP+vjSK3wupnMDVQ5abCuN4mzV2=0w@mail.gmail.com>,
   J Percival <perciv.js@gmail.com> wrote:
> Hi Frank. My response was to Jeroen's e-mail. I assume he was talking about
> the actual quotes key on a US keyboard, rather than anything related to
> accented characters.

He wrote about the " and ' keys, which are essentially accent keys. He
also wrote '...pressing the key does not generate output.' which is the
same thing that's happening here when any of the accent keys are pressed
without AltGr. That's why I replied to him, suggesting he'd try the
AltGr route. As he hasn't responded yet, we can't be sure whether it is
the same issue or not yet, though.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <CAFWmK8yBw+vMAZjrVbQKtP+vjSK3wupnMDVQ5abCuN4mzV2=0w@mail.gmail.com>,
J Percival <perciv.js@gmail.com> wrote:
> Hi Frank. My response was to Jeroen's e-mail. I assume he was talking about
> the actual quotes key on a US keyboard, rather than anything related to
> accented characters.

He wrote about the " and ' keys, which are essentially accent keys. He
also wrote '...pressing the key does not generate output.' which is the
same thing that's happening here when any of the accent keys are pressed
without AltGr. That's why I replied to him, suggesting he'd try the
AltGr route. As he hasn't responded yet, we can't be sure whether it is
the same issue or not yet, though.

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

Hi Frank. My response was to Jeroen's e-mail. I assume he was talking about the actual quotes key on a US keyboard, rather than anything related to accented characters.

Incidentally, Alt-Gr combos don't seem to produce them for me, so that may be a Linux/Windows difference but it isn't something I'm remotely familiar with so I'll leave it to the devs to clarify if/when they have the chance.

Regards,

James

On Fri, May 25, 2018 at 6:13 AM, Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:

In article <CAFWmK8yJ3gCobRh33R0CnfBm3AkN3rFNqJVEVW+9+nN0nvBSDA@mail.gmail.com>,
   J Percival <perciv.js@gmail.com> wrote:
> I'm not familiar with using a US keyboard under RiscOS and I only have a UK
> one here, but I tried setting country to USA on RO5.22 (through *configure
> country, *country, and *keyboard) and it acted as I would have expected
> with " changing to @ and vice-versa, etc.

This isn't about setting the keyboard handler to US or UK. It's the
(right) keys not working as they should. I have to hold down the AltGr
key whenever I want an accent to show up. Not just the " and ', by the
way. All of them, `, ^ and ~ as well.

I think it may have something to do with the host using a handler like
'UK international with dead keys'. Somehow RPCEmu doesn't respect that
and treats it like 'UK international with AltGr'.

Regards,
Frank

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <CAFWmK8yJ3gCobRh33R0CnfBm3AkN3rFNqJVEVW+9+nN0nvBSDA@mail.gmail.com>,
J Percival <perciv.js@gmail.com> wrote:
> I'm not familiar with using a US keyboard under RiscOS and I only have a UK
> one here, but I tried setting country to USA on RO5.22 (through *configure
> country, *country, and *keyboard) and it acted as I would have expected
> with " changing to @ and vice-versa, etc.

This isn't about setting the keyboard handler to US or UK. It's the
(right) keys not working as they should. I have to hold down the AltGr
key whenever I want an accent to show up. Not just the " and ', by the
way. All of them, `, ^ and ~ as well.

I think it may have something to do with the host using a handler like
'UK international with dead keys'. Somehow RPCEmu doesn't respect that
and treats it like 'UK international with AltGr'.

Regards,
Frank

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

I'm not familiar with using a US keyboard under RiscOS and I only have a UK one here, but I tried setting country to USA on RO5.22 (through *configure country, *country, and *keyboard) and it acted as I would have expected with " changing to @ and vice-versa, etc.

It seemed to make no difference whether Windows was configured for a US or UK keyboard (which was a bit of a surprise - maybe the devs can explain). Do you perhaps have some other layout configured in Windows that could be the issue?

On Thu, May 24, 2018 at 6:33 PM, Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:

First, thank you very much for the new version delivered! I like it a lot and on my Windows 10 machine for example I'm finally getting good sound output compared to previous versions of RPCEmu.

I'm running into the following though that I would like to share. On a keyboard configured in RISCOS to USA the key with " and ' signs does not seem to be working anymore. This I experience when for example running the !Hopper game with the keys as they come standard. The same in !Edit, pressing the key does not generate output.

Setting the Keyboard back to the default UK does not help. I've run RPCEmu 0.9.00 with 5.23 and 5.25 riscos roms, but this also doesn't solve it. In RPCEmu 0.8.15 the key is working. Could this therefore be version 0.9.00 related or is it something in my setup? I'm running RPCEmu on Windows 10 Home riscos 5.24 StrongARM 128MB Sound on

Best regards,
Jeroen Vermeulen







---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

In article <e61569ed-2cbf-6de2-1cde-ef504cc24e18@home.nl>,
Jeroen Vermeulen <jeroen-vermeulen@home.nl> wrote:
> I'm running into the following though that I would like to share. On a
> keyboard configured in RISCOS to USA the key with " and ' signs does not
> seem to be working anymore.

Try holding down AltGr (aka right Alt) while you press one of those
keys. Yes, it's bloody annoying but at least I got my accent keys
working like that (Linux based RPCEmu with UK keyboard).

@devs: Any idea for a proper fix for this, by the way?

Regards,
Frank


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.0 Keyboard key not working?

First, thank you very much for the new version delivered! I like it a
lot and on my Windows 10 machine for example I'm finally getting good
sound output compared to previous versions of RPCEmu.

I'm running into the following though that I would like to share. On a
keyboard configured in RISCOS to USA the key with " and ' signs does not
seem to be working anymore. This I experience when for example running
the !Hopper game with the keys as they come standard. The same in !Edit,
pressing the key does not generate output.

Setting the Keyboard back to the default UK does not help. I've run
RPCEmu 0.9.00 with 5.23 and 5.25 riscos roms, but this also doesn't
solve it. In RPCEmu 0.8.15 the key is working. Could this therefore be
version 0.9.00 related or is it something in my setup? I'm running
RPCEmu on Windows 10 Home riscos 5.24 StrongARM 128MB Sound on

Best regards,
Jeroen Vermeulen







---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Tumblr

As of the last few days, every time I try to view a Tumblr URL I get a
https://www.tumblr.com/privacy/consent?redirect= page instead.
I'm assuming this is something to do with the new data protection rules, but
since I don't even have a Tumblr account and have no means of getting past
this roadblock to view what was intended as publicly broadcast data it's
rather annoying.

I was trying to follow a webcomic published there, and I've got a couple of
useful articles bookmarked...


--
Harriet Bazley == Loyaulte me lie ==

Cole's Law: Thinly sliced cabbage.

Re: [Rpcemu] RPCEmu 0.9.0 / PipeDream bug

Keyboard patch: Fixes handling of F10 (Windows) and potential stuck keys when a menu is open (all platforms but possibly only an issue on Windows).

Tested on Windows 10/64-bit only. I won't be providing a binary (for various reasons) so you'll either have to patch the source and recompile or wait for an official release.

diff -r b0e396f600d9 src/qt5/main_window.cpp
--- a/src/qt5/main_window.cpp    Sat May 05 21:00:45 2018 +0100
+++ b/src/qt5/main_window.cpp    Sat May 19 18:33:56 2018 +0100
@@ -421,6 +421,8 @@
 void
 MainWindow::keyPressEvent(QKeyEvent *event)
 {
+    if (!accepting_kbd_input()) return ; // Block keyboard input (to non-GUI elements) in problematic cases
+
     // Special case, handle windows menu key as being menu mouse button
     if(Qt::Key_Menu == event->key()) {
         emit this->emulator.mouse_press_signal(Qt::MidButton);
@@ -485,6 +487,8 @@
 void
 MainWindow::keyReleaseEvent(QKeyEvent *event)
 {
+    if (!accepting_kbd_input()) return ; // Block keyboard input (to non-GUI elements) in problematic cases
+
     // Special case, handle windows menu key as being menu mouse button
     if(Qt::Key_Menu == event->key()) {
         emit this->emulator.mouse_release_signal(Qt::MidButton);
@@ -501,6 +505,22 @@
     }
 }
 
+// Check if accepting keyboard input
+bool
+MainWindow::accepting_kbd_input()
+{
+    // Not accepting if any menus open (solves potential 'stuck key' issues)
+    QList<QWidget *> menus = menuBar()->findChildren<QWidget *>() ;
+    QList<QWidget *>::const_iterator iter = menus.constBegin() ;
+    QList<QWidget *>::const_iterator iter_end = menus.constEnd() ;
+    while(iter < iter_end)
+    {
+        if ((*(iter++))->isVisible()) return false ;
+    }
+
+    return true ;
+}
+
 void
 MainWindow::menu_reset()
 {
@@ -1208,8 +1228,8 @@
 /**
  * windows pre event handler used by us to modify some default behaviour
  *
- * Disable the use of the virtual menu key (alt) that otherwise goes off
- * every time someone presses alt in the emulated OS
+ * Disable the use of ALT and F10 on the host which select the menubar
+ * every time they're pressed in the emulated OS
  *
  * @param eventType unused
  * @param message window event MSG struct
@@ -1223,21 +1243,21 @@
     Q_UNUSED(eventType);
 
     MSG *msg = static_cast<MSG*>(message);
+   
+    // Handle 'alt' and F10 key presses directly that would otherwise select the menu
+    // Fake the key press and release and tell windows/qt to not handle it
+    if((msg->message == WM_SYSKEYDOWN || msg->message == WM_SYSKEYUP) &&
+        (msg->wParam == VK_MENU || msg->wParam == VK_F10))
+    {
+        BYTE scanCode = (BYTE) (msg->lParam >> 16) ;
 
-    // Handle 'alt' key presses that would select the menu
-    // Fake 'alt' key press and release and then tell windows/qt to
-    // not handle it
-    if((msg->message == WM_SYSKEYDOWN || msg->message == WM_SYSKEYUP)
-        && (msg->wParam == VK_MENU))
-    {
         // Use the code from the qt key press and release handlers
-        // 0x38 is the windows native keycode for alt
         if(msg->message == WM_SYSKEYDOWN) {
-            held_keys.insert(held_keys.end(), 0x38);
-            emit this->emulator.key_press_signal(0x38);
+            held_keys.insert(held_keys.end(), scanCode);
+            emit this->emulator.key_press_signal(scanCode);
         } else {
-            held_keys.remove(0x38);
-            emit this->emulator.key_release_signal(0x38);
+            held_keys.remove(scanCode);
+            emit this->emulator.key_release_signal(scanCode);
         }
         return true;
     }
@@ -1245,4 +1265,4 @@
     // Anything else should be handled by the regular qt and windows handlers
     return false;
 }
-

Re: [Rpcemu] RPCEmu 0.9.0 / PipeDream bug

I have a fix for the Windows F10 issue and another menu/keyboard related problem in the works but I want to test it a bit more and make sure I haven't broken anything in the process before posting it.

Regards,

James

On Fri, May 18, 2018 at 6:12 PM, J Percival <perciv.js@gmail.com> wrote:

I've reproduced this. As Bryan says, it's a case of the emulated Shift key getting stuck. This appears to happen when Shift is pressed at the same time as accessing a menu (including 'File', 'Disc', etc). Why does Shift-F10 do it? I think because that's the Windows shortcut for opening the context menu (same as right-click by default).

As a workaround, pressing Shift again will 'unstick' it.

On Fri, May 18, 2018 at 2:55 AM, Bryan Hogan <rpcemu@helpful.demon.co.uk> wrote:

In message <db0911f756.old_coaster@old_coaster.yahoo.co.uk>
          Tony Moore <old_coaster@yahoo.co.uk> wrote:

> Under RPCEmu 0.8.15, shift-f10 works as intended. However, under RPCEmu
> 0.9.0, shift-f10 corrupts the filing system

I think you are over dramatising that a bit! If it corrupted the
filesystem then rebooting wouldn't help.

> not possible to close an open file, or directory. Clicking on the close
> icon causes the object to be iconised to the iconbar.

That sounds like the Shift key status has become stuck On, so RISC OS
thinks every click you do is a shift-click.

It could be some accessibility feature that is intercepting the
shift-F10 shortcut and "holding" the shift status, but I don't have
Windows so can't check.

Bryan.

--
RISC OS User Group Of London  -  http://www.rougol.jellybaby.net/
RISC OS London Show           -  http://www.riscoslondonshow.co.uk/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 / PipeDream bug

I've reproduced this. As Bryan says, it's a case of the emulated Shift key getting stuck. This appears to happen when Shift is pressed at the same time as accessing a menu (including 'File', 'Disc', etc). Why does Shift-F10 do it? I think because that's the Windows shortcut for opening the context menu (same as right-click by default).

As a workaround, pressing Shift again will 'unstick' it.

On Fri, May 18, 2018 at 2:55 AM, Bryan Hogan <rpcemu@helpful.demon.co.uk> wrote:

In message <db0911f756.old_coaster@old_coaster.yahoo.co.uk>
          Tony Moore <old_coaster@yahoo.co.uk> wrote:

> Under RPCEmu 0.8.15, shift-f10 works as intended. However, under RPCEmu
> 0.9.0, shift-f10 corrupts the filing system

I think you are over dramatising that a bit! If it corrupted the
filesystem then rebooting wouldn't help.

> not possible to close an open file, or directory. Clicking on the close
> icon causes the object to be iconised to the iconbar.

That sounds like the Shift key status has become stuck On, so RISC OS
thinks every click you do is a shift-click.

It could be some accessibility feature that is intercepting the
shift-F10 shortcut and "holding" the shift status, but I don't have
Windows so can't check.

Bryan.

--
RISC OS User Group Of London  -  http://www.rougol.jellybaby.net/
RISC OS London Show           -  http://www.riscoslondonshow.co.uk/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 / PipeDream bug

In message <db0911f756.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:

> Under RPCEmu 0.8.15, shift-f10 works as intended. However, under RPCEmu
> 0.9.0, shift-f10 corrupts the filing system

I think you are over dramatising that a bit! If it corrupted the
filesystem then rebooting wouldn't help.

> not possible to close an open file, or directory. Clicking on the close
> icon causes the object to be iconised to the iconbar.

That sounds like the Shift key status has become stuck On, so RISC OS
thinks every click you do is a shift-click.

It could be some accessibility feature that is intercepting the
shift-F10 shortcut and "holding" the shift status, but I don't have
Windows so can't check.

Bryan.

--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Persistant error boxes.

In article <bda0be06-f5c4-12e2-aaa1-aa8107a6d148@codethink.co.uk>,
Michael Drake <michael.drake@codethink.co.uk> wrote:
> On 13/05/18 18:08, lists wrote:

> > I get persistant error boxes from NetSurf "failing to identify the
> > authenticity of an SSL certificate". Whether I select reject or
> > accept, I get a continued succession of similar boxes and can end up
> > with dozens all over the screen.

> Do you have a URL that causes it?

Not really. These are messages that come in in HTML format, so I have to
open the HTML attachment using !NetSurf. Whereupon I get the error boxes.

> Which version of NetSurf?

Currently CI #4321

Email software is !POPStar/!Pluto

> Have you tried the latest build?

I will.

> http://ci.netsurf-browser.org/builds/

> Cheers,

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

Re: Persistant error boxes.

On 13/05/18 18:08, lists wrote:

> I get persistant error boxes from NetSurf "failing to identify the
> authenticity of an SSL certificate". Whether I select reject or accept, I
> get a continued succession of similar boxes and can end up with dozens all
> over the screen.

Do you have a URL that causes it?

Which version of NetSurf?

Have you tried the latest build?

http://ci.netsurf-browser.org/builds/

Cheers,

--
Michael Drake http://www.codethink.co.uk/

[Rpcemu] NX/XD/DEP patch

I've added support for DEP on Windows and re-done the 'length' calculation for Linux (mprotect) as it looked wrong to me (potentially including one too few or one too many pages if I'm not mistaken). I've only tested it on a Windows10/64-bit host however.

Not sure if the mailing list can handle file attachments so I'll just copy/paste the diff:

diff -r b0e396f600d9 src/codegen_amd64.c
--- a/src/codegen_amd64.c    Sat May 05 21:00:45 2018 +0100
+++ b/src/codegen_amd64.c    Sun May 13 23:20:07 2018 +0100
@@ -32,11 +32,7 @@
 #include "mem.h"
 #include "arm.h"
 #include "arm_common.h"
-
-#if defined __linux__ || defined __MACH__
-#include <sys/mman.h>
-#include <unistd.h>
-

Persistant error boxes.

When I clink on an Ebay message trying to persuade me to buy something,
one I have just received is headed "make a note of this", many others say
"trending"

I get persistant error boxes from NetSurf "failing to identify the
authenticity of an SSL certificate". Whether I select reject or accept, I
get a continued succession of similar boxes and can end up with dozens all
over the screen.

The only way I can clear the screen is by shutting NetSurf down completly

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

Re: [Rpcemu] Compiling problem under Linux (Ubuntu 16.04.4)

Thank you so much! As I said, 'this is (was) probably a very awkward and perhaps even a stupid question'. Much obliged for pointing me in the right direction.

Op 13-05-18 om 02:24 schreef Matthew Howkins:

On 9 May 2018 at 22:13, Peter Veltmans <peter.veltmans@skynet.be> wrote:

This is probably a very awkward and perhaps even a 'stupid' question.
   I tried to compile rpcemu-0.9.0 under Linux (Ubuntu 16.04.4). However, the download did not comprise a 'configure'-file. So... no go.

Or did I miss something?

Have you looked at the updated build instructions for 0.9.0?
See https://marutan.net/rpcemu/linuxcompile.html

Matthew

Re: [Rpcemu] Compiling problem under Linux (Ubuntu 16.04.4)

On 9 May 2018 at 22:13, Peter Veltmans <peter.veltmans@skynet.be> wrote:

This is probably a very awkward and perhaps even a 'stupid' question.
   I tried to compile rpcemu-0.9.0 under Linux (Ubuntu 16.04.4). However, the download did not comprise a 'configure'-file. So... no go.

Or did I miss something?

Have you looked at the updated build instructions for 0.9.0?
See https://marutan.net/rpcemu/linuxcompile.html

Matthew

[Rpcemu] RPCEmu 0.9.0 / PipeDream bug

Using:

Windows 7 Pro / RPCEmu 0.9.0 / RISC OS 6.20 / PipeDream 4.55.04

The PipeDream command file 'key' at
HostFS::HostFS.$.!Boot.Choices.Users.Single.PipeDream.CmdFiles.key
contains the following command

\cdf |i "shift f10" |i "\bps|m" |m

Its purpose is to bind the keypress Ctrl B P S (Block Protection Set) to
shortcut shift-f10.

Under RPCEmu 0.8.15, shift-f10 works as intended. However, under RPCEmu
0.9.0, shift-f10 corrupts the filing system, in such a way that it is
not possible to close an open file, or directory. Clicking on the close
icon causes the object to be iconised to the iconbar.

To restore the filing system, it is necessary to re-start RPCEmu.

A workaround for the problem is to avoid the shortcut and instead use
the keyboard to enter Ctrl B P S which works as intended, and doesn't
corrupt the filing system.

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Compiling problem under Linux (Ubuntu 16.04.4)

This is probably a very awkward and perhaps even a 'stupid' question.

I tried to compile rpcemu-0.9.0 under Linux (Ubuntu 16.04.4). However, the download did not comprise a 'configure'-file. So... no go.

Or did I miss something?

Please advice, if you would be so kind.

Thanks in advance!

Sincerely,

Peter


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

On Mon, 7 May 2018 at 11:25, Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> However... There seem to be problems with Full Screen mode on older
versions
> of Ubuntu which are Unity-based.

> Full Screen works fine on my desktop system, running Gnome-based GUbuntu
> 16.04, but on my laptop, which is still on Unity-based Ubuntu 14.04,
> full-screen just makes the window into one which can't be moved or
expanded.
> All of the window furniture is still visible, as are the Unity menu bar
and
> quick launch bar. The RISC OS iconbar is therefore lost off the bottom of
> the Linux screen.

I've had a web search around the issue and I think you might have run into
a Unity issue.

Could you test on this machine with a different window manager to confirm?

Unfortunately if this is an issue with Unity I do not think that it will be
fixed by Canonical, as you mention they've moved over to gnome.

Peter


--
Peter Howkins
peter.howkins@marutan.net
https://www.marutan.net/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

I'm re-sending this post because the first attempt seems to have
vanished. Apologies if it appears twice.

On 5 May 2018, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> A new version of RPCEmu is available

[snip details]

Very many thanks for this excellent upgrade - here it's running RO 6.20
on Windows 7 Pro - the fullscreen mode is a considerable improvement.

However, I'm not sure that I fully understand how fullscreen is intended
to work. For the moment, I've used anymode to create a display having
the same resolution as the screen, 1920x1080. Settings > Fullscreen mode
then removes the Windows window furniture, so that the RPCEmu display
fills the screen. All well and good. However, if RPCEmu is quit, and
re-started, it is necessary to activate Settings > Fullscreen, all over
again. Is it possible to configure RPCEmu to start in Fullscreen?

Thanks again

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

On 7 May 2018 01:07:59 BST, Peter Russell <peter@pipalya.com> wrote:
>Peter Howkins wrote on 5 May :
>
>> A new version of RPCEmu is available, X.X.X
>Is there anything for Mac users? Peter

I had a look at this for the preview version. The bottom line is the keyboard doesn't work. The problem is that Qt on the Mac, and in fact any other Mac libraries, don't expose raw key events. Even if we worked around that, it means that we can only read a limited number of keys, some special keys don't work, and keystrokes would move around depending on whether your Mac was set to US, UK, QWERTY, AZERTY, etc.

It might be worth doing, but the overall experience won't be very nice. Best I can suggest at the moment is running the Linux or Windows versions under VirtualBox. Those at least should have a working keyboard.

Theo

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

On 5 May 2018, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> A new version of RPCEmu is available

[snip details]

Very many thanks for this excellent upgrade - here it's running RO 6.20
on Windows 7 Pro - the fullscreen mode is a considerable improvement.

However, I'm not sure that I fully understand how fullscreen is intended
to work. For the moment, I've used anymode to create a display having
the same resolution as the screen, 1920x1080. Settings > Fullscreen mode
then removes the Windows window furniture, so that the RPCEmu display
fills the screen. All well and good. However, if RPCEmu is quit, and
re-started, it is necessary to activate Settings > Fullscreen, all over
again. Is it possible to configure RPCEmu to start in Fullscreen?

Thanks again

Tony




_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

On 5 May, Peter Howkins wrote in message
<CANc9Z=wcH=dy6dOk6nvaZJMJG5TvtXX5NxBQjqWvuGxVPop85Q@mail.gmail.com>:

> A new version of RPCEmu is available, X.X.X
>
> http://www.marutan.net/rpcemu/
>
> The two major changes in version 0.9.0 compared to previous versions.
>
> * Changed to the Qt5 library for the GUI. Previously we used the Allegro
> 4 library and additional win32 code.

Thanks for the new version -- overall the new interface is a lot better than
the old one on Linux.

However... There seem to be problems with Full Screen mode on older versions
of Ubuntu which are Unity-based.

Full Screen works fine on my desktop system, running Gnome-based GUbuntu
16.04, but on my laptop, which is still on Unity-based Ubuntu 14.04,
full-screen just makes the window into one which can't be moved or expanded.
All of the window furniture is still visible, as are the Unity menu bar and
quick launch bar. The RISC OS iconbar is therefore lost off the bottom of
the Linux screen.

Has anyone else noticed similar behaviour, or have I got some oddity with my
setup here?

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

> On 7 May 2018, at 1:07 am, Peter Russell <peter@pipalya.com> wrote:
>
> Peter Howkins wrote on 5 May :
>
>> A new version of RPCEmu is available, X.X.X
> Is there anything for Mac users? Peter

Can't answer this. But I am about to give the new version a thrash on my Mac. I failed to get RPCemu running OK for networking a couple of months back, but the core RPC emulation worked well with the latest test build. Since then there has been a new VirtualBox for Mac, a new Ubuntu LTS and now a glorious new RPCEmu, so I hope to give them all a Big Thrash starting later today.

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

Peter Howkins wrote on 5 May :

> A new version of RPCEmu is available, X.X.X
Is there anything for Mac users? Peter

--
Peter M Russell
Adelaide, South Australia
Using RISCOS on Iyonix - immune to all M$ viruses

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

Thanks for the new release. Seems to work great!

On Sat, May 5, 2018 at 9:43 PM, Peter Howkins <rpcemu.howkins@marutan.net> wrote:

A new version of RPCEmu is available, X.X.X

http://www.marutan.net/rpcemu/

The two major changes in version 0.9.0 compared to previous versions.

  * Changed to the Qt5 library for the GUI. Previously we used the Allegro 4
    library and additional win32 code.
   - The GUI is shared by all platforms, reducing maintenance work.
   - The Linux/BSD builds gain the full GUI that previously was Windows only.
   - The full-screen mode should no longer crash.
   - The full-screen mode uses software scaling. It will no longer resize
your
     host OS desktop and it preserves the aspect ratio of the emulator video
     modes.
   - The clock "drift" (where host and emulated clock move apart) should be
     gone. As such we no longer enable the SyncClock module by default.
However
     if this is causing you an issue please report it.
  * Changed the threading model of the program so that the GUI is in a
separate
    thread from the emulation of the machine.
   - The most obvious change from this is that opening menus and configure
     windows does not halt the emulation of the machine while you work with
     them.

Additional fixes in version 0.9.0

  - Linux: Support being built as a position independent executable (PIE),
this
    allows the 64-bit recompiler builds to work without modification on Linux
    distributions which compile all software as PIE by default (e.g. Ubuntu
    16.10 and later)
  - Windows: HostFS date stamps should be correct regardless of Daylight
    Savings Time flag.
  - ARM Core: STM with store of R15 should vary with processor type (x86
    recompiler).
  - ARM Core: STRT/STRBT with store of R15 should store same value as
STR/STRB.
  - The mouse will work when changing between A7000 and RPC models without
    having to rerun RPCEmu.
  - In 'Follow host mouse' mode, enabled support for OS_Word 21,3 'Move
Mouse',
    also supports BBC BASIC 'MOUSE TO'.
  - In 'Follow host mouse' mode, the mouse should work correctly if you
change
    to fullscreen, change RISC OS mode and leave fullscreen again.
  - Clang compiler is now recognised when writing to the log file.

A special thanks to the members of the RPCEmu mailing list who helped with
testing these wide-ranging changes.


Matthew Howkins
Peter Howkins

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.102

On Mon, 26 Mar 2018 at 04:00, J Percival <perciv.js@gmail.com> wrote:

> Good to hear! I had a feeling it was Qt-related.


A quick update to let you know that a work-around in qt was discovered and
is included in the recent 0.9.0 release of RPCEmu. As such the escape key
works.

Peter

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.0

A new version of RPCEmu is available, X.X.X

http://www.marutan.net/rpcemu/

The two major changes in version 0.9.0 compared to previous versions.

* Changed to the Qt5 library for the GUI. Previously we used the Allegro 4
library and additional win32 code.
- The GUI is shared by all platforms, reducing maintenance work.
- The Linux/BSD builds gain the full GUI that previously was Windows only.
- The full-screen mode should no longer crash.
- The full-screen mode uses software scaling. It will no longer resize
your
host OS desktop and it preserves the aspect ratio of the emulator video
modes.
- The clock "drift" (where host and emulated clock move apart) should be
gone. As such we no longer enable the SyncClock module by default.
However
if this is causing you an issue please report it.
* Changed the threading model of the program so that the GUI is in a
separate
thread from the emulation of the machine.
- The most obvious change from this is that opening menus and configure
windows does not halt the emulation of the machine while you work with
them.

Additional fixes in version 0.9.0

- Linux: Support being built as a position independent executable (PIE),
this
allows the 64-bit recompiler builds to work without modification on Linux
distributions which compile all software as PIE by default (e.g. Ubuntu
16.10 and later)
- Windows: HostFS date stamps should be correct regardless of Daylight
Savings Time flag.
- ARM Core: STM with store of R15 should vary with processor type (x86
recompiler).
- ARM Core: STRT/STRBT with store of R15 should store same value as
STR/STRB.
- The mouse will work when changing between A7000 and RPC models without
having to rerun RPCEmu.
- In 'Follow host mouse' mode, enabled support for OS_Word 21,3 'Move
Mouse',
also supports BBC BASIC 'MOUSE TO'.
- In 'Follow host mouse' mode, the mouse should work correctly if you
change
to fullscreen, change RISC OS mode and leave fullscreen again.
- Clang compiler is now recognised when writing to the log file.

A special thanks to the members of the RPCEmu mailing list who helped with
testing these wide-ranging changes.


Matthew Howkins
Peter Howkins

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

CSS stress-test

Found these today:
https://github.com/cyanharlow/purecss-francine
https://github.com/cyanharlow/purecss-vignes
https://github.com/cyanharlow/purecss-zigario

They are pictures created entirely in HTML+CSS!

I didn't expect NetSurf to display them properly, but thought it would
be interesting to see it try.

The most striking thing was that it displays the page many times
larger than the screen, so you have to reduce scale loads to see
what is going on.

The first image it doesn't show anything (I was expecting to see
*something* even if it didn't look much like the preview).
The other two it has a reasonable attempt. Nothing obviously wrong,
just things not implemented, I think.

Chris

Re: This is regarding libdom library.

On 02/05/18 02:59, Naveen Kumar wrote:
> Hi Team,
>
>
> I have a requirement to create the library 'libdom' from open  source
> code :- http://www.netsurf-browser.org/projects/libdom/
OK.

> I was not able to find symbols ' GetCurrentColumnNumber ' , '
> GetCurrentByteIndex ' ...etc
> Prefix 'denaliXML' was exected to add as a prefix for those symbols.

None of those symbols have ever been used by or provided by
LibDOM from the NetSurf project.

> .The existing library 'libdom0.4.a' on some other machine  was working
> fine and able to find all the symbols in the log above ..the new library
> which i created from opensource dont have those symbols.I have
> downloaded the code with version 0.3.2,  is it because of version
> change? Please help .....

We have never made a LibDOM 0.4 release. The latest is 0.3.2.

It sounds like the libdom0.4.a that you were using before is
either a completely different project (that happens to share
the same name) or a fork of libdom with changes that have never
been upstreamed to us.

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: This is regarding libdom library.

On Wed, May 02, 2018 at 07:29:09 +0530, Naveen Kumar wrote:
> When i try to use that library in our build system. i am facing the issue
> below.
[snip]

Those errors look suspiciously like you are missing a library or similar in
your link stage.

Remember that linking resolves left to right, pulling symbols from right to
left (on the link line)

So if you have libdom.a at some position in your link, you will then need the
provider of those XML symbols *after* libdom.a on the link line.

I hope that helps,

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

This is regarding libdom library.

Hi Team,

I have a requirement to create the library 'libdom' from open  source code :- http://www.netsurf-browser.org/projects/libdom/ 

I have downloaded the source and its dependent libraries and able to install and create final libdom.a (version 0.3.2) library.

When i try to use that library in our build system. i am facing the issue below.

Log:-

../build/Linux/Release/modules/libdenbase.a(xmlutil.o): In function `xmlParserFormatError':

xmlutil.c:(.text+0xa1c): undefined reference to `denaliXML_GetCurrentColumnNumber'

xmlutil.c:(.text+0xa2c): undefined reference to `denaliXML_GetCurrentByteIndex'

xmlutil.c:(.text+0xa81): undefined reference to `denaliXML_GetCurrentLineNumber'

xmlutil.c:(.text+0xab2): undefined reference to `denaliXML_GetErrorCode'

xmlutil.c:(.text+0xaba): undefined reference to `denaliXML_ErrorString'

../build/Linux/Release/modules/libdenbase.a(xmlutil.o): In function `xmlParserParse':

xmlutil.c:(.text+0xb94): undefined reference to `denalidomReadDocument'

I was not able to find symbols ' GetCurrentColumnNumber ' , ' GetCurrentByteIndex ' ...etc

Prefix 'denaliXML' was exected to add as a prefix for those symbols.

.The existing library 'libdom0.4.a' on some other machine  was working fine and able to find all the symbols in the log above ..the new library which i created from opensource dont have those symbols.I have downloaded the code with version 0.3.2,  is it because of version change? Please help .....

Thanks,

Naveen