• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 101 end: 200]

world-name: r4wp

Group: #Red ... Red language group [web-public]
I want ALSO View/VID, which is being kind of dismissed here both 
by Doc and Kaj :-)

 Absolutly not, I'm just saying that I will build a native GUI solution 
 first, a View-like solution is not my priority but it is welcome. 
 If nobody makes a View-like engine, nor wraps R3/GUI engine, I will 
 consider making one myself when I will have more time.
Doc - I know - what I want is - free form GUI, not necessarily a 
native GUI, which is mostly good for forms like apps imo. Or just 
please show me particles.r 1.6KB demo rewritten to GTK :-)
I created a folder and blank file for you Petr: %Red/GUI/Petr's Wishlist.txt
As far as the wish for a View/VID native solution goes, I wish that 
as well. Maybe it will be possible when the JIT compiler becomes 
reality to easily adapt Rebol's VID. 

It does not have to be complete like VID, a basic set of widgets 
will get you a long way.  

Other solutions are a really good thing too, but looking at GTK and 
myself I find it hard to find out how to get GTK on my mac. It is 
not a standard dmg file I can download and install and it works. 
Other GUI solutions require integration of their package or having 
the end user of your programs to find out how to get it running on 
their machine. That kind of thing can be a real showstopper to global 

I know Doc is working hard and has already stated he intends to come 
up with a VID like native solution. So we can let him focus and be 
silent ,or we can comment and discuss letting him know we do care.
His point is, that with PC world converging towards touch, tooltips 
are a dead concept - there is no hover with touch devices. I also 
myself don't like pop-up menus, etc. - it was always a hell, and 
requires special treatment in GUI subsystems ....
We were more focused on lower-level things. The console wasn't much 
of a priority, especially since we were intending to implement it 
in the R3-GUI, and that wasn't there yet.
Actually, I am trying to send 50 on a month basis. Now r3 gui project 
is temting too, but i would have to see the project outline, eg seeing, 
that cyphre will be paid to update the engine to use hw acceleration, 
etc. I would love View engine to be useable with Red too. I ca feel 
some excitement last few weeks, fort both r3 and red projects :-)
Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 


You can see the source code for this GTK+ demo here:


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).
Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
Just donated 50 EUR so that Red project does not feel bad by my move 
to donate also to R3/Android/GUI :-)
Here's the code for the Red GUI IDE:
It requires a completely extra set of bindings, including to the 
Java VM and the GUI. We're thinking about it
No one will be impressed with normal GUI, email, database capabilities, 
even if it's 10x more productive, but anything multimedia, video, 
3D, etc. which demonstrates "modern" capabilities, and beats other 
solutions, works on mobile, etc., then they're much more likely to 
go "hmmm".
It's best to use the MSDOS folder. The Windows folder is less complete 
and compiled as GUI apps, so no command line output
I just never got very far with Boron.  I donated to it when I thought 
it could be a viable open source alternative to R2, but it's feature 
set never evolved enough to be useful for work, like R2.  That's 
been the problem with ALL REBOL related language tools for the past 
6 years or so.  That's what made/makes R2 attractive.  A full stack 
of usable tools for creating applications.  If the Saphirion guys 
and Doc build usable tool sets with mature GUI, sound, database, 
3D, etc. APIs, then people will begin to use those languages.  Boron 
never had any of those features implemented in a user friendly way.
I still think as a full package, REBOL is better, but R2 is getting 
old an losing support for new, cool features and platforms.  If Cyphre 
is succesful porting R3 GUI to Android, it's got a chance.  If Doc 
gets Red evolved enough to support basic features, it's got a helluva 
I hardly ever email, but if he has no plans, it would be a nice second 
backend that I could make for my GUI dialect
Yes, I had a copy of your newer C library binding.  I compared the 
relevant sections and added in the appropriate parts.  Now I have 
a different problem, possibly due to me not running a gui on my Raspberry 
Pi.  Don't know yet if OpenCV requires a GUI to operate or not.
I think OS X GUI apps are fundamentally dual-threaded, with one thread 
for the GUI, so in the best case, it uses two cores more or less
Red executables (like R3 ones or any other language compiled to native 
code) are not supported directly by mobile OSes. So, it needs to 
be loaded and called from Java or obj-c, hence the need for shared 
library support.

The experiments with Red/System on Android was limited because using 
such approach, you can't have access to the higher level API, can't 
access GUI and need an hack to get it loaded. My goal was just to 
check that Red/System toolchain was able to produce code that runs 
on Android.
Group: Announce ... Announcements only - use Ann-reply to chat [web-public]
Please note: Scroll through the pages since we sometimes combine 
several MDP files into one page. Not the nicest way at the moment, 
but works best to avoid so many pages. The start is for MDP itself 
and R3-GUI / Actors.
Massive R3-GUI documentation brought online. ATT: The docs still 
referr to the old GUI model. We are going to clean everything up 
in the next weeks.
does it currently have GUI support?
I moved the GTK+ and GLib bindings for Red/System into CONTEXTs. 
If you have written code on top of it, you need to adapt the interface.

The GUI dialect is now basically independent from GTK; that is, it 
could be implemented unchanged for other GUI toolkits.
I wrote a simple text editor in the Red GUI dialect:

With Doc's latest Red fixes, I was able to write a very simple IDE 
in the GUI dialect:


You can write either regular Red code or GUI dialect code, and execute 
it with respectively the Do or View button. Do executes the code 
in the interpreter, so no compilation is needed, but the current 
limitations of the interpreter apply.

The code is only 25 lines, but at Brian's request, I'll post that 
in the #Red channel.
New Android release:

URL		: http://development.saphirion.com/experimental/

Direct URL	: http://development.saphirion.com/experimental/r3-droid.apk

-fixed console output crashes
-implemented CLIPBOARD:// device
-implemented BROWSE
-added circular buffer to console

-release has now correct platform, version, product and build information
-fixed console input hang-on-destroy bug

Please give it a try and have fun.

This release is a milestone since now Rebol CORE is fully done for 
Android. We will now start to get the VIEW (graphics) to Android. 
As soon as we have this, R3-GUI should almost work on Android too.
Then again, maybe not with the MSDOS version, that is compiled to 
not be a GUI program
Cross-Post from Android group:

New release of Rebol3 with graphics on Android: http://development.saphirion.com/experimental/r3-droid.apk

-enable CTO and OTC functions
-fix window offset
-fix image! / loaders pixelformat color order
-fixed close button action (RL_Init failed?)
-improved WAIT
-added clipping(slow atm but works)
-added RESIZE/ROTATE events
-improved JNI calls synchronization
-added native keyboard input
-updated built-in R3-GUI version

Note this release is very early alpha so expect unstable situations 
or even crashes. Feel free to report bugs or any other feedback.

This gets us again one step closer to be able to create Android apps 
with Rebol. Simple, small, fast. :-)
I'm happy to announce that we reached a major milestone and can release 
a bunch of new things. All the different versions have been merged 
into one code base which makes things easier for us. This was possible 
because the new 'retargetable' graphics subsystem was finished. This 
allows us to port R3 to other platforms much easier. Next target 
Linux. The release in detail:

R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the 
feedback. The main milestone we achieved was to switch to a resolution 
independent sizing system. This will scale your app widgets to look 
the same on different display densities. It's a must have for mobile 
apps. Next for R3-GUI is to create a simple mobile style set. Fruther, 
we are going to push the source code to GitHub. We need to setup 
a bridge to our internal SVN repository, so expect some back and 
forth on Github before we are stable.	Anway feel free to help making 
R3-GUI better and better.

Android: This release is now mostly the same as the windows release. 
So, yes, it's now possible to do R3-GUI apps on Android. I'm going 
to try to run Treemapper on it. Type DEMO to see the new R3-GUI version 
and widget scaling feature. Post as much screenshots / pictures of 
your phone as you can :-)

R3/Saphir: New version for windows with bug-fixes are released as 
well. Please see the change-log on our web-site for details.

Thanks to all the team for the great work! I really think we are 
close to have a very good and stable base with R3 and R3-GUI. Looking 
forward to see more and more people joining and becoming part of 

http://development.saphirion.com			(Change Logs, Downloads, etc.)
http://development.saphirion.com/experimental	(Android)
https://github.com/organizations/saphirion		(Documentations)
I wrote a quick & minimal example illustrating how to use R3-GUI 
together with R3's async HTTP:

For relevant platforms, I added extra versions of my Red interpreter 
console distributions to my downloads:


They provide versions that include my 0MQ binding for messaging. 
Previous interpreter distributions didn't include it, because on 
most platforms, you have to install the 0MQ library as an extra. 
Further, people may need 0MQ with the GTK+ GUI binding, or without 
it on servers and embedded systems. So there are two new distributions 
in each platform folder:


red-core-message is meant for servers and includes bindings for the 
C library, cURL, SQLite and 0MQ. In addition, red-message also includes 
the GTK binding and is meant for GUI programs. For Windows, most 
of these interpreters are in the MSDOS/Red/ folder, but I also added 
a version that is meant to start scripts for GUI programs, so it 
doesn't open an extra console window:

As an example, the interpreter to run messaging scripts on a Raspberry 
Pi without GUI is here:


The interpreter to develop GUI scripts on x86 Linux to communicate 
with a Raspberry Pi is here:


A similar interpreter to develop GUI scripts on Windows to communicate 
with a Raspberry Pi is here:


As always, for Windows you also have to download the libraries that 
are included in the repository, according to the instructions here:

In conjunction we did a new R3-GUI release as well.

added DETAB flag support
fixed TEXT-AREA issues
fixed TEXT init-size handling
fixed SIZE-TXT bug
built new R3GUI release (version 4897)
delete "experimental" layout-sizing-independent.r3
improve rouding
move docs/r3-gui/ to documentation/r3/r3-gui/

remove documentation/r3/r3-gui/license/ directory containing obsolete 
Copyright notice update
license update
typo fixed
Rounding correction
improved rotate event handling

improved drag handling code (removed duplicate gui-events/drag reference)
improved android text input handling
fixed progress resizing
improved text-able cell font handling
fonts are antialiased by default on android now

Robert, Cyphre Congratulations !! Correct link for r3-gui is: http://development.saphirion.com/resources/r3-gui.r3
(no .r)
We have pushed our R3-GUI sources to Github. The project was cleaned 
up, old stuff removed etc. So it should be in pretty good shape. 
We keep the GibHub repository in sync with our internal SVN repository. 
We will further take a look at pull requests and take your feedback 
into our main line. You can find the repository here:

Group: Rebol School ... REBOL School [web-public]
in GUI result should not be like blobks, correct?
you mean i should put my gui sfter print
ALERT is not meant for CGI, it is a GUI function.
...but the GUI example should be in the repertoire of beginners, 
don't you think? (and it even "caught" Cyphre, so he asked me how 
to do it properly using function, so I had to tell him: "don't")
On the GUI, yes, perhaps.
REBOL, under Windows, uses its own GUI "console" window, so you have 
to trick it. Running it in CGI mode should work for you.
have you done 'load-gui before you run the script?
Group: #Red Docs ... How should Red be documented [web-public]
Here is script which I used to cerate it... note that there are not 
existing links in Carl's reference (in the GUI section). Hope Red 
will have documentation without such a silly errors.

I think I should chime in here because I am one of those people who 
are not naturally inclined toward the programming arts. I see that 
many of you realize that the docs have to reach a vast audience from 
novice to expert. That will involve using different methods of presentaton 
and detail. How would you envision the database to look like. If 
we could create something pretty complete then I think all the desired 
above could be accomplished. For what it's worth I use the following:

The rebol dictionary - to look up words and usage I can't remember, 
try to decipher some functionality I need, hopefully find examples.

The View docs - to find out how things works and to remember how 
certain words work

Everything I can find on Parse - This is one subject that is all 
over the place.

Nick's tutorial and Reboltutorial - To learn about topical items 
that one can do in rebol such as sound and animation.

Altme - Asking all of you, especially Henrik, if I can do something 
and how or when something doesn't work.
Rebol.org - To find scripts that do things I need to do

Google - OK, this is generic and possibly obvious but when I am trying 
to figure something out, it's "Rebol ..."

The above items are my  most used resources and not exclusive. Note, 
for me the R3 docs were harder to navigate, especially a few years 
ago when I was looking at the GUI stuff. To me at least they seemed 
all over the place.

So, if one were to analyze that usage, it may help to develop something 
that can accomplish those different needs.
About wikis, I would probably prefer that the document structure 
is fixed, and then each page can be a wiki. We had problems early 
on with the R3 GUI documentation that someone changed it.
Someone also wrote a makedoc GUI, didn't they? Are there tools like 
that for managing a doc base? I also agree with some earlier comments 
about some commercial sites having very good docs. How do they do 
Gabriele wrote a MakeDoc GUI a long time ago.
Group: !REBOL3 ... General discussion about REBOL 3 [web-public]
Saphirion is building up a repository with a nightly-build infrastructure. 
We are currently working on these things:
- Win32 builds, mostly done

- automatic check of other repositories for changes and pulling changes 
for test-builds
- merging our host-kit to get View and R3-GUI
- cross-compiling for Win, OSX & Linux
Than we will extend R3-GUI and the automatic test-framework. The 
latter is used to regression test all R3 builds over and over again. 
We currently have about 50 cases that crash R3. These need to get 
Essentially we need a consistent GUI  SDK that will create apps for 
both platforms..
Porting the GUI to a new platform is a lot of work
You could write the GUI in the native technology, and do the core 
app in an embedded R3 library
Useless to us.  We'll stick with Javascript/HTML/CSS/Java/JSON if 
we can't use a REBOL dialect for GUI's.
What is the state of the GUI on R3?
Win32 only. Draw in the /View builds. R3-GUI from Saphirion on top 
of that.
Afaik R3 GUI is workably stable. Saphirion has a non-trivial app 
running with it.
Than we will extend R3-GUI and the automatic test-framework. The 
latter is used to regression test all R3 builds over and over again. 
We currently have about 50 cases that crash R3. These need to get 
Would it make sense to for a start, have a non-native GUI running 
on top of OpenGL? This is what you see from a bunch of different 
groups out there - e.g. using Lua (Corona, Gideros, Muai), Python 
(Kivy), Haxe, etc. This could maybe be done more quickly since I 
think there's already been some experimenting with OpenGL by Maxim, 
and others (Cyphre?). I guess taking this route would depend on how 
much work it would be to make Draw run over OpenGL, but it would 
open the door to a certain class of apps (games, graphics)..
Yes, imo the first thing, whichou would REALLY help R3 GUI, would 
be to create a new skin - boxy, simplified, modern. No capsules and 
old OS9 Apple design hybrids ...
Henrik, Pekr, yes R3GUI needs to get some nicer skin but otherwise 
in terms of functionality it's a proof the current R3 can be used 
for GUI apps even now.
Is the r3-gui available on the Saphirion site download section the 
most recent version? It's from March this year, and I seem to remember 
some activity on it after that point.
r3-gui is available. It's not the latest release but works. We are 
going to update it. I need to fix the web-site project as it's currently 
Robert, is it possible to show JPEG images using your R3 GUI ?
Pekr, R2's console was GUI on Windows, not a real console app. Carl 
had wanted to make an R3 console like R2's but better, in the R3 
GUI. We just never got around to it.
Carl's blog was about the inline text-mode problem, trying to solve 
the open-a-window bug. That wasn't about the planned GUI, it was 
about fixing the existing console.
If you are talking about the existing R3 console, the problem was 
that he couldn't make a real console-mode R3 program without losing 
functionality that he only knew how to support in GUI-mode programs, 
and he couldn't make a GUI-mode app use the Windows console without 
allocating its own console window, which lost all of the advantages. 
It's not to say that this can't be done, just that noone who had 
the interest and ability to do this had made the effort, because 
it was low-priority for the contributors at the time. With more contributors 
now, perhaps this will get fixed.
Also, is it possible to just compile it that way in the first place? 
And is it possible for such an app to bring up a GUI, say so that 
it can run console scripts and GUI scripts?
Such an app can bring up a GUI, yes.

However, it will always pop up a console window (which can be closed 
immediately, but this will result in the "console flashing" effect 
some dislike).
Yes, we should built it that way in the first place. We only recently 
added building in GUI mode, to avoid a crash with console mode binaries 
when launched from shells other than cmd.exe. (Another bug that needs 
But note that most (all?) official RT R3 alpha builds have been GUI 
mode binaries.
Brian, I build the Red examples in both modes, so you can try out 
the effect if you want. MSDOS/console programs can open a window, 
but Windows/GUI apps don't seem to be capable of using stdout, at 
least not to a console they're started from
Is this the best way to perform this check in http://www.rebol.com/r3/demo.r:

errout case [

 not value? 'size-text ["This R3 release does not provide a graphics 
 system."] ; this one
	load-gui <> 0.2.1 ["Wrong GUI version for this test script."]
	true [none]
ah, those services. I wrote some doc about what do I don't like about 
them (naming conventions, other design issues (from my pov)), and 
Carl told me, that he is going to completly overhaul them once GUI 
is finished. That never happened though ....
I didn't use R/S except for testing/playing but I like to see it 
working. But I think we have other priorities like GUI, Android etc., 
R3 itself..
Has anyone had any contact with Steven Solie about the Amiga R3 build? 
 I see from his site http://solie.ca/that in 2010/11/23 he had R3-GUI 
up and running.
It's actually pretty easy to see how they managed it. It was:

- A multi-language IDE (not a programming language, people already 
get those for free)
- With a GUI with an emphasis on modern graphic design (pretty!)
- With a fancy demo (more pretty!)

- With an initial focus on programming languages and development 
platforms that are already popular (built-in customer base)

Powerful IDEs are some of the only development tools that people 
are still willing to pay money for (i.e. Visual Studio). Most people 
can't choose what language they write in, but they more often can 
choose their IDE. And for crappy-but-IDE-friendly languages, an IDE 
can make all the difference in your productivity. They're not as 
helpful for really powerful extensible languages like Rebol or Perl, 
unless the language is so bad that just about anything would help 
(Perl). Plus, since an IDE is an end-user app you can afford to GPL 
it, since the only stuff built on it are add-ons - that doesn't work 
for programming languages unless they have a clear distinction between 
user code and built-in code that is distinct enough to not violate 
the GPL distinctions, because most of the competition is permissive 
- and without the GPL restrictions there is nothing to sell, so there 
is no business model to get a return on investment.

It's nice to point to other open source projects and say "See! We 
could have done that!" but unless those are comparable projects their 
success isn't comparable either.
OK, so it's a single-language IDE aimed primarily at the education 
market, still with a nice-looking GUI if not as modern, with an appeal 
based on Apple-fan nostalgia for HyperCard. That's a tougher sell, 
but since it's education market you can get away with GPL/commercial, 
and since it's Apple-nostalgia you can raise that much money from 
merely thousands of investors instead of the millions that you'd 
need if you were going for a less-well-off target market. Makes sense, 
but it's still nice to see.
And a better console, built on R3-GUI. And better text-mode console 
support for systems where you can't use a GUI.
BrianH: well, I was long time a proponent of R3. What attracted me 
most were devices, even more modularity, etc. But - let's not be 
deluded. If you are careful enough, you could see, that ppl mention 
some things here or in regards to Red, eg. asking - is View going 
to be available? Let's not ingore, that many ppl started to use REBOL, 
because it was kind of complete package - console, call, dbases, 
networking, gui ...
Still, all of that can be added on or retrofitted, that's the whole 
point of being modular. Having them implemented and available before 
3.0 would be a good idea for marketing reasons (don't knock those, 
they're important), but not having them done before 3.0 won't break 
user code the way not doing core semantic changes before 3.0 would. 
People will be working on these before 3.0 comes out because they 
need them, and the ones that we as a community consider to be the 
most important to include in 3.0 will likely be worked on the most. 
But the great part about that stuff is that it doesn't have to be 
developed as part of R3 itself, just like the GUI is being developed 
The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 

Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.

Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.
We can always build a "shortcut" dialect like VID on top of R3-GUI, 
for common simple patterns, once R3-GUI is complete.
The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:

1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one

2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?

There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?
I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...
About excuses - there are imo no excuses. As I said - we are just 
few, and ppl are busy with other things too. As for those really 
needing GUI right now (it's not me for e.g.), I think, that some 
ppl prefer what they know R2 VID, RebGUI, just because of typical 
entry barrier. There is nothing wrong with R3-GUI imo, and from what 
I studied in the past, it is much better system than R2. Sometimes, 
it is difficult to find out real reasons, why ppl react this way, 
or that way, I just dunno ...
I think that there is no way to take it as offense. Noone said a 
bad word against R3-GUI today imo ...
To all people who want to dare in Documentation R3 GUI labirinth 
, you may use http://rebol.informe.com/wiki/view/Main_Pageto help 
Group: !R3 Building and Porting ... [web-public]
Android and iOS.  How much of a bounty do I need to offer for R3 
with GUI on Android?
Btw.. with High Resolution Displays coming these days, the HW powered 
GUI is a must. The CPU rendering will be just for making high quality 
assets for GPU. http://www.tomshardware.com/news/Intel-Higher-Resolution-Displays-Coming,15329.html
Actually, Oldes, that's a great idea!  R3's new GUI could be built 
to utilize OpenGL by default.  That way, the GPU would handle all 
the graphics calls, and R3 would have 3D capabilities built-in as 
a bonus!  This would probably even make porting to Android and other 
platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?
It is. OpenGL ES2.0. As well as Android. Actually I don't think there 
is a chance to do GUI on these platforms without OpenGL.
Bo, I think if we don't make drastic changes to the GOB mechanism 
we should be safe when building anything on top of the GOB datatype. 
The gob! is in fact abstraction layer between the "VIew engine" and 
any "GUI framework" written in REBOL.
So as take this example:

We have now R3GUI framework which runs quite well on the current 
View engine (although this engine was build in 2 weeks during the 
very early R3 alpha work so it's kind of Q&D prototype ;))
(BTW should I mention the R3GUI is much better than R2 VID?)

Anyway, the R3GUI works on current View engine. When I tried to change 
the engine so it uses OpenGL accelerated AGG the R3GUI still worked 
without any problem (except visual bugs caused by incomplete OpenGL 
code implementation of the new prototype).

SO from that example you can see the "View engine" and "GUI framework" 
are two independent things and can be developed or even exchanged 
From the "design architecture" POV we should focus on stabilizing 
the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. 
If these layers are fine-tuned you have great base that allows us 
make experiments at the low-level graphics and also as well at  the 
high-level GUI abstraction layer.
So to sum up my thoughts:

-anyone can even now start working on it's own great GUI dialect 
for R3, or contribute and enhance to already existing R3GUI (latest 
version will be published soon)

-anyone can create own great low-level graphic engine for XY platform 
or just one native binding for specific os

-work of these people won't be useless if they stuck to the current 
gob! datatype

Ofcourse we can do slight changes to the gob!s or draw dialect as 
well but these should be always easy to incorporate in already existing 
code that relies on them
The R3 I mentioned is R3-View. I'm going to publish it with the latest 
R3-GUI. Announcement will follow.
Group: Community ... discussion about Rebol/Rebol-related communities [web-public]
This is a periodic posting of community links along with activity 
levels for discussion dedicated to Rebol and Rebol-like languages. 
The intent is to bring a dispersed community together by providing 
the current list of places where the community gathers along with 
reasonably accurate activity indicators for each place. This list 
will be posted in each location weekly or bi-weekly so that anyone 
dropping by will not have to look far in order to learn where else 
things are happening.

Currently the activity stats are gathered manually and postings are 
also not automated. This will hopefully change as the requisite scripts 
to scrape and post automatically are developed. This updated list 
will eventually be available at http://rebol.comas the site is cleaned 
up post Rebol open sourcing. 

# Chats

## R3 Chat

This is the primary forum for Rebol 3.0. It runs from any Rebol console 
in a text mode, but a GUI version is planned.
- Run R3, type chat and follow the instructions (all platforms.)

- Type "help" for more information or visit R3 DevBase Chat Forum 

- To view public messages from any web browser go to RebDev mobile/phone 
interface (http://www.rebol.net/cgi-bin/rebdev-web.r).

- Problems? Please contact Rebol Technologies at (http://www.rebol.com/cgi-bin/feedback/post2.r).
Activity: 4 messages this month

## Rebol chat on Stack Overflow (http://chat.stackoverflow.com/rooms/291/rebol)

- Note that you will need a reputation of 20 in order to be able 
to post in the chat. 

- You can gain this minimal reputation (essentially a spam filter) 
by participating in the Stack Overflow group of sites. 
Activity: 380 messages this week

## AltME Worlds

A private instant messaging system where rebolers hang out 24/7. 
The current world dedicated to Rebol and Rebol-like language discussion 
is called REBOL4
- Get client at http://www.altme.com/download.html
- connect to the 'rebol-gate' world with user/pass, guest/guest
- request account on REBOL4 world in the REBOL4 request group

Web archives of public groups, first to last in the most active world, 
REBOL4, as well as the dormant world, REBOL3:
REBOL4 (http://www.rebol.org/aga-groups-index.r?world=r4wp)
Activity: 286 posts last 6 days
REBOL3 (http://www.rebol.org/aga-groups-index.r?world=r3wp)

# Forums

## Rebol Facebook group (http://www.facebook.com/groups/rebol)
A new special interest group for Facebook users.
Activity: 26 messages this month

## Rebol Google+ community (https://plus.google.com/communities/100845931109002755204)
Activity: 4 messages this month

## Rebol Google Group (https://groups.google.com/forum/?fromgroups#!forum/rebol)
Activity: 43 messages this month

## Synapse EHR Rebol Forum (http://synapse-ehr.com/community/forums/rebol.5)
A web-based forum for R2 and R3, provided by Synapse EHR
Activity: 13 messages this month

## RebelBB France (http://www.digicamsoft.com/cgi-bin/rebelBB.cgi)
A simple forum, written in Rebol, for French speakers.
Activity: 140 messages this month

## Nick's Rebol Forum (http://rebolforum.com/index.cgi)

A micro-forum (just a few lines of Rebol) hosted by Nick Antonaccio. 
(Note: the captcha question is first.)
Activity: 79 messages this month

# Q&A (Question & Answer)

## Stack Overflow questions on Rebol
Activity: 219 questions tagged
Activity: 2 questions tagged
You can use GUI tools ... such as Git GUI
I'm just wondering (really, just that): is dev capacity (i.e. Cyphre 
GUI. other's on OSX, 64 bit) the limiting factor to accelerate in 
the short term? Or money?
I would want R3 on Android with GUI, GPS, Camera support. And R3 
64 bit Linux server side ("Core").
101 / 28671[2] 345...2526272829