World: r3wp

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

if we do that, there might be a need to define a behavioral model 
as part of the skin, but I'm not sure how much it encompasses. There 
are some little details that I expect to work in a specific way in 
OSX, which don't work in Windows, and vice versa. This means that 
styles may not implement these behaviors directly, but that is probably 
difficult to avoid.

I think we should categorize typical differences, such as:


- whether certain buttons are activated on mouse-down or mouse-up.

- whether a button action is activated when dragging out of a button 
and releasing.
- whether default follows tab focus.
- etc.


Then these could possibly be implemented in styles and abstracted 
away from the style as a behavioral profile for a specific OS.

Mozilla apps are not a good place to observe native system behaviour, 
because they use their own toolkit

Abstracting the things Henrik lists would be very nice

That is why I checked with native Windows dialog box :-)

Small status:


The Internet these days seems to be composed of a series of disk 
crashes (instead of tubes). Both Robert and Rebolek are suffering, 
which slows down communications, so no updates lately.

Maybe you should realy use github, at least for the open part of 
your project.

as we get a better arrangement on how to do that properly, yes. I 
think we can do this by pushing nightly from the server.

OT: Our new server us much more reliably setup. Three RAID systems, 
failover power/ethernet/..., back to the cloud every 6h etc.

If something happens at least we should be back to full steam in 
much less time.

nice! that's the way. just made a similar setup with SSD/PCI-SSD 
and a spacious raid 5 for the data storage.
for ultimate speed I can recommend PCI-SSD Instead SATA SSD.

We have a big project that needs Android TabletPC and Phones to run 
on.

How difficult would it be to have a an R3 GUI for these touch based 
devices ?

R3 would have to be ported ...

one interim solution would be to have at least core plus cheyenne 
and local webserver webapp ... but cheyenne will not be ported to 
R3 soon enough for you  imo ...

At this point it would be easier to use R3 as a preprocessor to generate 
apps that are implemented in Java than it would be to use R3 directly.

then why to use R3 at all? If R3 can't be ported or used, it failed 
...

Ok, I have understood we should talk about REBOL on Android in a 
couple of years from now.

But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch

It is clear this path is not suitable for our project. We should 
look at Java.

At this point, the only plans I have heard people making for Android 
were to make an R3 host that would act as a plugin for the Android 
native API model, so that R3 would be a native library to supplement 
apps that are primarily written in Java. No talk of AGG yet in those 
plugins though.

hmm, but that sucks then .... I can's see anything special for the 
the touch - it is just different mouse. Multitouch is different beast, 
but I work with touchscreens since 2003 - some of them simply simulate 
mouse ....

Of course that would depend on what native plugins are allowed to 
do on Android. I haven't even heard of a fully native GUI app for 
Android (they might exist but I haven't heard of it), only CLI apps.

and they dare to call it a platform? Without a free GUI?

They do have a free GUI. It's just that it's written in Java.

we will see - unless someone physically starts experimenting with 
at least core ARM port, it is all preliminary ...

maybe we should move groups ....

I bought an Android phone (as opposed to an iPhone or WP7) specifically 
for this purpose.

Yes.

The other chance would be to see REBOL ported to the JavaVM...

It might be easier to port to Dalvik than to the JVM - I haven't 
checked yet.

Brian, my project will start on February. There is no time to wait 
for anything REBOL based.

Right.

We are planning an Order Entry application which needs a tablet/mobile 
phone and a Server counterpart.

The only way to use REBOL in this scenario would be the application 
which retrieves order for the local ERP from the server.

Order entry apps seem like the kind of thing that the existing Android 
GUI would be able to do easily.

I figured that direct use of REBOL wouldn't be something you could 
do now for your project. But it could be useful eventually to someone 
else in your situation, so it is worth discussing :)

The R3 GUI will eventually need multitouch support and support for 
modern touch-screen devices (meaning: not treating touch like a mouse). 
That support would be portable to a variety of devices, some of which 
would be running OSes that the R3 GUI already runs on.

Android can do SDL, so it should be able to do the host kit and AGG, 
in several ways

Also, Boron should be easy to port to Android

Whether you reimplement in Java or port the host kit, you would need 
the same mapping from the Java semantic model to the REBOL semantic 
model; they have little in common. That will probably be the hardest 
part to get right, especially if we do a native r3lib port and just 
rewrite the host.

If you were to port it the same way as SDL, you would have very little 
to do with the Java subsystem

Brian, this cuts the wings of a REBOL based order entry for mobile 
devices.

Later in development it is planned to use static touch screen based 
PC. This could be done in REBOL but the other part needs to be programmend 
in a solid, tested and rich enviromnent.

Maybe release 3.0 of the order entry project will be in our beloved 
language.

Kaj, if you have any links to fully native GUI applications for Android 
that don't use any Java or Dalvik at all, please post them. I have 
been looking for any indications that such things are possible, and 
haven't found any yet. The SDL seems to be linked as an NDK library, 
not as something used to make native apps. All of the native apps 
I've seen are command-line only and not runnable from an icon in 
the applications list. I'll keep looking.

It looks like you might be able to use a combination of the standard 
NDK and a third-party cross-compiler to make fully native GUI apps. 
You would get the libraries from the NDK, including SGL (that's Skia 
Graphics Library, not SDL, it owns the framebuffer). I haven't seen 
anyone try to do this yet but since it may be possible then it might 
have been done already by someone.

first of all R3 must get out for windows, linux & mac !!!!!!   regards

I have zero experience with Android but from what I read here I can 
guess what is needed:

-R3 should be ported as native Java plugin including the agg (in 
C/C++)

-we should write Andriod OS compatible Java based application wrapper 
which will include basic app event loop, window+framebuffer management, 
networking+file IO (?)

-this Java wrapper will be able to open window, detect all the OS 
events etc. and pass it to the Rebol plugin

I'd guess that if R3 was a viable way to develop for Android, we'd 
see a higher uptake of the language than from any of the other (non 
mobile) platforms.

there's a gold rush in mobile app development (still) happening

I had quick glance at the Android examples....it seems my guessing 
was not too off. Also it looks like the android developement is very 
simmilar to the J2ME stuff  in the basic sense so I might give it 
a try in their emulator to see what is possible ;)