How far can I translate RapidQ to XBasic?  

I find it nice that William Yu got the opportunity to earn his wage by joining REALbasic though if RapidQ really ceases to be further developed I would find it a pity as it has a lot of good potentials and offers a good easy learning curve in programming for Windows / Linux without needing to pay $300,- for it.

As I have peeked a little bit into a couple of RapidQ example code I notice that RapidQ deals a bit the same way with system calls that Visual Basic does in some way. Though as I peeked into socket functionality, RapidQ pretty much uses the same methods to make TCP/IP connections that XBasic does.
However XBasic's Internet library does not support UDP (yet).
RQ looks like a VB interface with a QB mentality. More or less there are overlays with XBasic for this matter.

RapidQ does not use runtime libraries you need to distribute along with your executable.
XBasic in the first place does use a runtime library however, you can implement it into your executable be it that the size of your exe will naturally grow.

RapidQ also supports Direct-X and MySQL, something there is no interface for in XBasic yet.

MySQL can be supported in XBasic as it is released GPL though, if RapidQ uses this library William Yu is violating the GPL concept as RapidQ should be Open Source in that case.

The reason why Direct-X is not supported as a core library is that Linux doesn't have an exact similar functioning Direct X version. It does not mean Linux has no Direct Hardware approach libraries, but discussions on egroups about implementing Direct X functionality lead to the suggestion using a multi-platform library like SDL because the functionality of the interface can remain the same and keeps the portability rate of your source code high.

This strong part of XBasic is one of the fundaments Max Reason build XBasic on and the XBasic developers community intend to keep this fundament as strong as possible to prevent XBasic users releasing sources that can't use half the functionality in Linux that it uses in Windows.


So when all the Windows specific things that aren't implemented in XBasic, what leaves that for translation possibilities from RapidQ to XBasic?
XBasic splits up visual functionality from action functionality (GUI Vs programming) as I see that RapidQ mixes visual stuff into the same function as the background routine parts.

Also as I see it, converting from R to X would be from top-down (RapidQ) to Left-Right (XBasic).

For each window XBasic generates two functions;

Suppose we have a window called "MyWindow".
XBasic would generate:
MyWindow()    ' The function that creates and handles window functionality (visual dialogue processing)
MyWindowCode()   ' The function that handles interactivity with the user (background interface processing)

The MyWindows() handles the creation of a window (properties and aspects), but also minimizing / maximizing and resizing options; Anything that deals with the window and its elements within

The MyWindowsCode() handles keyboard trapping, mouse-click-events and every other trapped system message that is sent to this function.
 
Converting aspects from RapidQ to XBasic is not easy as you have to deal with mixed functionality that has to be unraveled,  a simple example:

Menus in a window:
create MenuBar as QmenuItem
      create File as QmenuItem
        caption = "Open"
        checked = 1
        onclick = OpenFile
      end create 

The above RapidQ code has a background event and a user interface dialogue event.

The MyWindow() would have this:

        XuiMenu        (@g, #Create, 4, 4, 624, 20, r0, grid)
        XuiSendMessage ( g, #SetCallback, grid, &MyWindow(), -1, -1, $MenuBar, grid)
        XuiSendMessage ( g, #SetGridName, 0, 0, 0, 0, 0, @"MenuBar")
        XuiSendMessage ( g, #SetColor, $$Blue, $$White, $$Black, $$White, 0, 0)
        XuiSendMessage ( g, #SetColorExtra, $$BrightRed, $$LightYellow, $$Black, $$White, 0, 0)
        XuiSendMessage ( g, #SetBorder, $$BorderRaise1, $$BorderRaise1, $$BorderNone, 0, 0, 0)
        XuiSendMessage ( g, #SetTexture, $$TextureRaise1, 0, 0, 0, 0, 0)
        XuiSendMessage ( g, #SetFont, 240, 400, 0, 0, 0, @"MS Sans Serif")
        XuiSendMessage ( g, #SetFont, 240, 400, 0, 0, 1, @"MS Sans Serif")
        XuiSendMessage ( g, #SetTextString, 0, 0, 0, 0, 0, @"_File")
        DIM text$[1]
        text$[ 0] = "_File"
        text$[ 1] = "\tOpen"

The MyWindowCode() would have this part:

SUB Selection
                CASE $MenuBar                                           
                        SELECT CASE v0   'Which menutopic selected?

                                CASE 1  'File

                                        SELECT CASE v1    'Which subtopic selected?

                                                CASE 0 'Open

                                                      OpenFile(File$)

                                        END SELECT

                        END SELECT

END SUB

Okay, this was just one simple example and the XBasic code looks pretty much typing-work, though.....

I can give a couple of more but to be honest...:

Rebuilding from scratch works faster and way easier since you just open the GUI designer, paste a menubar in it and add the menu-items in the Text$[] array of the appearance menu then you just add the functionality in the MyWindowCode() "Selection" sub that is all auto generated by the GUI designer when ported to the program source: Yes most of the code above is generated, the only manual work I did was adding the Select case part for the menu and the OpenFile() call in the selection sub.

I wasted time once on a QB2XB converter and now I hardly want to know how to code in QB anymore... just try the beginners sections on how to make my first program and my first GUI program and you will find out that this ease of use is really true.