AltME groups: search

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.

Petr, in the currently available code, the GTK binding can't function 
without a callback from Red/System into Red; as Doc says, to pass 
GTK events into the Red GUI dialect engine. So far I constructed 
the callback the ugly way, but there's official support now

Actually, it's fairly simple, think about a GUI app that sends a 
click event to your Red/System binding, how do you pass the event 
to Red code if you can't call it from Red/System. ;-)

Is the Android GUI AWT?

Nope, AWT is an old GUI built-in Java, so it's handy for doing simple 
GUI demo.

I will do a prototype wrapping of the Android GUI API in a few days, 
so you'll be able to put your VID-like dialect on top of it. ;-)

what kind of GUI is Android using? It surely is not AWK, nor Swing? 
Just trying to orientiate myself ....

what kind of GUI is Android using?
 Its own one. See the Android.* classes in Android docs.

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

When I talk about spped it's related to display and GUI ...

I'm not sure you're much interested in learning how to do it using 
Java objects, do you? It can be done already, but in order to implement 
proper abstraction for Red, we need at least objects support. Also, 
getting the GUI layer done is higher priority.

Actually, you got an error message sent to your logcat. :-) Once 
things will be stabilized for 4.x support, I'll redirect printing 
to the GUI.

Also, to be able to see any output in DOS console from an encapped 
Rebol app, I needed to change a flag in the executable file (sub-system: 
`console` instead of `GUI`).

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:

http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip&name=examples

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

http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip&name=examples


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

Changes:
-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

Changes:
-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 
it.

Links:
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:

https://gist.github.com/earl/447e4e9510a68c308f6b

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

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


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/red-core-message
*/Red/red-message


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:

Windows/Red/red-message.exe

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

Linux-ARM/Red/red-core-message


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

Linux/Red/red-message


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

MSDOS/Red/red-message.exe


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


http://web.syllable.org/news/2012-11-18-20-47-Red-high-level-programming-language-first-alpha.html

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 
license
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

http://development.saphirion.com/resources/r3-gui.r

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:

https://github.com/saphirion/r3-gui

R3 droid is a nice work. Hope to see it with nice GUI elements.

so, can you make a GUI out of all this?

There's also the other way around: most GUI toolkits such as GTK 
have an OpenGL widget, so with my multi-backend design I can make 
OpenGL backends for the widgets of those toolkits. You'd have your 
regular widgets and then the option to use part of the window for 
3D

Kaj, I ran into Carl today in Home Depot and we talked about your 
SDL binding for Red.  Do you think it would be difficult to make 
a binding for R3?  Carl was saying that he thought it wouldn't be 
too hard to convert R3-GUI to run off of OpenGL instead of the current 
foundation (was it AGG?) so it could be hardware accelerated.

Just curious.

Carl must've been talking about writing SDL into R3-GUI then.  Sometimes 
(often) he speaks above my level.

In contrast to libraries like Qt and wxWidgets, FLTK uses a more 
lightweight design and restricts itself to GUI functionality. Because 
of this, the library is very small (the FLTK "Hello World" program 
is around 100 KiB), and is usually statically linked. It also avoids 
complicated macros and separate code preprocessors, and does not 
use the following advanced C++ features: templates, exceptions, RTTI 
or, for FLTK 1.x, namespaces. Combined with the modest size of the 
package, this leads to a relatively short learning curve for new 
users.[citation needed]


These advantages come with corresponding disadvantages. FLTK offers 
fewer widgets than most GUI toolkits and, because of its use of non-native 
widgets, does not have native look-and-feel on any platform.

Well, I have mixed feelings ... Carl simply gave up on Rebol and 
its message imo ... felt strange: " I'm no longer in the mode of 
convincing the world about Rebol. I've learned a lot over the last 
couple years in the trenches." ..... later .... "So, I know really 
well now that Rebol is not for every developer.... but it would get 
more interest if R3+GUI was easy to download an get running on a 
variety of those devices on your list."

Kaj, need full GUI.

Yes, no REBOL then. Red has the GTK GUI on Raspberry, but it's basic 
so far

Henrik, it looks like your wait for GUI on R3 on RPi won't be long, 
based on Robert's announcement he just made.

What is the link to download r3-gui.r3? There's incrrect link on 
the webpage, leading just to the same page, not target file ...

gui docs ...

Robert, Thanks for the R3-gui release.  Do you have a date for Rebol 
and view engine also being part of a source release?  


These where one of the most frequently recurring discussions at the 
devcon.

r3-gui.r3 is exactly as long as the MS build script for a Windows 
driver :-)

Thanks, Robert. Could you briefly describe somewhere (in just a few 
sentences) the workflow you use when working on/debugging r3-gui? 
i.e is it possible to stay in the same R3 instance and rebuild (do 
you even need to be using the monolithic r3-gui script when debugging?), 
reload the script safely, etc.

So to work on / debug R3-GUI (Cyphre please correct me, if I'm wrong):

;; Load INCLUDE (once)
>>  do https://raw.github.com/saphirion/include/master/include.r


;; (Re-)load R3-GUI (multiple times; assumes you are in the R3-GUI 
toplevel directory)
>> include %loader/loader.r3

Yes, the most efficient way(in Windows) is to setup INCLUDE+R3-GUI 
loader to be executed everytime you click on *.r3 script. I'm using 
that and every change to the R3GUI sources is then automatically 
"propagated" once I run any R3GUI script again.

Yes, the strategy Cyphre describes is ideal for immediate testing 
of any changes made to R3-GUI sources.

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 
fixing).

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 
separately.

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 
convinience.

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 
community.

100% of voters on http://rebol.informe.compoll aske for Linux GUI

Is there a GUI that currently works with Carl's last r3 alpha?

Is there an equivalent to Henrick's list-view in R3-gui?

Josh, there's an r3-gui group that might be a more appropriate place 
to ask.

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 
(http://www.rebol.com/r3/devbase/index.html).

- 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
http://stackoverflow.com/questions/tagged/rebol
Activity: 219 questions tagged
http://stackoverflow.com/questions/tagged/rebol3
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").

Than we have fundamental frameworks and libs like R3-GUI etc. this 
is a mix of Rebol code and enhancements on the C/D level.

eg. the descriptive text of rebol 

--

It's a messaging language ` 'rebel' not 'ree-ball' ` code is data 
and data is code ` CGI? Yes ` 40+ platforms ` only 250K-500K ` console 
or GUI ` Yes, just a single file ` commercial versions = same core 
+ ODBC, SSL, and more - shallow learning curve, amazing depth ` keep 
IT simple ` if you liked "The Matrix"...
--


is lengthy and not focus... it also do not need to be at the top 
of every page...maybe it should go below 'About'

Could add/replace some of that with "cross-platform, CGI, console 
and simple GUI dialect etc.."

Back in February (!), Anton wrote:

<<By the way, something that I never really liked is the short rebol 
description at the top of rebol.org.>>

OLD TEXT: <<It's a messaging language. 'rebel' not 'ree-ball'.

 code is data and data is code. CGI? Yes. 40+ platforms. only 250K-500K.

 console or GUI. Yes, just a single file. commercial versions = same 
 core + ODBC, SSL, and more -

 shallow learning curve, amazing depth. keep IT simple. if you liked 
 "The Matrix"...>>

We may be slow, but we get there:   http://www.rebol.org

The banner text has been updated to ready pretty much what Anton 
suggested.

Thanks Anton!

Dont know that eally well myself. what i firued out: usually (debian, 
suse) startup-scripts are in /etc/init.d. on debian there is a /etc/init.d/skeleton 
as base for own script. then there are the runlevels in /etc/rc?d/. 
links there go to /etc/init.d/ an tell the system what to start/stop. 
the numbers in the filenames are the priority, lowest run first. 
Usually there is a gui-tool like yast or ksysv which scans /etc/init.d/ 
for scripts and makes the appropriate links. tricky things are to 
write the startup-script, to figure out which runlevel to use and 
how the os figures out what to stop. although if you dont need that 
runlevel smartness, because you call it on boot and let it be killed 
by shutdown, you can just use a normal bash-script.

(runlevels tell which servers etc to run. so there is one with everything 
off for maintenance, one for console-use, console with network, console+network+gui-login, 
these with and without network, maybe some others)

Festival is a software made in Scheme ( a Lisp clone) that allow 
voice synthésis (debian pakage are available on bedian.org website 
and can be acceded using Synapse GUI debian DLand Install software).

To run my solution I simply make a bash that tests if festival is 
yet running or not and then runs it (I'm using 1.2.1 REbol version 
for linux ...) and then runs my GUI software ;)

we have looked at it and at the same time looked at phpsavant 
 http://phpsavant.com/yawiki/index.php?page=StartExample


for us, our key concerns is maintenance from the developer point 
of view. We want the team to stick to one language (or markup)... 
there will be times in a project, that you may not have the luxury 
of a designer...so the developer still end up working on the apps 
GUI (or look-n-feel).

have you seen http://www.nvu.com/? Gecko based. They aim for something 
like Dreamwaver. IIRC, with dreamwaver, if you have e.g. some module, 
you can provide "plug-in", simply that web designer will parametrise 
you module using GUI and the rest is done under-the-hood ....

I do intend to make glass the standard high-end GUI engine in REBOL 
.

rebol.org library already have tagging for the scripts.


Both in terms of levels ["Beginner" "Intermediate" "Advanced"] as 
well as the domain ["cgi" "gui"] etc...


Perhaps there is a way to feed the cookbook examples into rebol.org 
and let the Library be the holding place for future cookbook examples.


There are '3 major' rebol sites (those with rebol in the domain). 
And they are rebol.com, rebol.net, rebol.org.

It is not incredibly clear whether certain docs should be in .org 
or .net. 


Other suggestion to consider is how can we leverage off works done 
in various sites and avoid duplication. Why not let rebol.org be 
the host for cookbooks as well?


I would think new comers will prefer to find both cookbook examples 
and other contributed scripts all in one location. Rebol.org also 
lets you search the mailing list.

Terry, I understand Oldes'  POV,  their tools but really hard to 
use. The language as the foundation for GUI programs is beter than 
the actual GUI programs.

Thanks Oldes, I will try that. The dialect and AS are becoming clearer 
now with all the info you have given me. I look forward to writing 
lots of cool things. Thanks for the hint about the two main parts. 
I wondered how they were connected as most of the AS tutorial have 
you create something with the GUI then add the AS part.

Rebol/Flash dialect (RSWF) version 2.5.0 is available!
compressed: http://box.lebeda.ws/~hmm/rswf/rswf_latest.r(89kB)

uncompressed: http://box.lebeda.ws/~hmm/rswf/rswf_2.5.0.r(331kB) 

as colorized HTML: http://box.lebeda.ws/~hmm/rswf/rswf_2.5.0.html
 (885kB) 

What's new:

- New swf-parser included which replaces old exam-swf function (useful 
for importing foreign SWF files)

- Added implementation of Class definitions for SWF versions 6 and 
higher (I have to create some examples)

- Added new 'trace function into actions (which can be use to compile 
swf files with or without trace calls easily)

- 'require and 'include now accepts block of files or urls (I should 
modify my rswf code colorizer to show included files as well)


Here is also new example how to include first of GUI elements: http://box.lebeda.ws/~hmm/rswf/example/swf8-cliphandler

In the future I would like to create something like mini Layout dialect 
which will be used for better positioning of the new GUIs I'm working 
on.

Version 2.9.0 ... now with Calendar GUI and fixed one nasty bug in 
'IF compilation after 'EITHER rule
http://box.lebeda.ws/~hmm/rswf/example/swf8-layout-calendar

and one more reason - to hack a default Flash gui components is for 
me much more difficult than make my own from scratch

If I can throw my two cents here. Terry is right to complain, because 
you can feel he cares, it's not destructive criticism. Pekr is saying 
he's a realist, but to me he sounds more like a dreamer (no offense).Flash 
is a Virtual Machine that lives in the browser. Rebol is a VM that 
lives on several OSes. Flash VM is present on 99% of the browsers. 
Rebol VM is not present  on browsers (plugin doesn't count because 
last time I tried it wouldn't install, and last version is more than 
a year old), and it is present on OSes of a small number of creative 
developers and hobbyists. If I had to develop a commercial app for 
the web, Flash and Flex give me extensive documentation, and a whole 
framework. Rebol can't compete with Adobe, and should not. Last week, 
I developed a GUI in Rebol and Rebgui that would have taken me four 
times longer in any other graphical toolkit, and I had a knack at 
it. But this app is for internal use. Rebol is a great language, 
and I would like to see it evolve as a computer language, not as 
a throw it all in kind of gizmo. It should go Open Source, because 
RT doesn't have the means to provide versions for all platforms. 
Where is the rebol for NetBSD? Last version is 2001. If RT hasn't 
the resources, let the developers do it. I want to run rebol on an 
internet tablet. I had wanted to run rebol on a palm (not anymore 
because Palm is deas, sort of). But the Nokia tablet run debian linux. 
There is no reason for the unabailability of rebol. It is just a 
matter of building it and packaging it. Who has the time for this? 
Plenty of people, they're just not at RT, because there people are 
busy with more important things (like developing the product).