AltME groups: search

I opened a new document in my usual text editor to paste the entire 
message text into it, so there was no other field involved.

download latest version:
http://www.pointillistic.com/open-REBOL/moa/files/renote.zip

macro-editor:

http://www.pointillistic.com/open-REBOL/moa/files/renote-macro-editor.png

I also did a bit of gui polishing:
http://www.pointillistic.com/open-REBOL/moa/files/renote-6.png

GLASS RELEASE 002
---------------------------

released last week, but posting it here to make it easier to find, 
since the GLASS group has a lot of discussion in it....

http://www.pointillistic.com/open-REBOL/moa/files/glass-r002.zip


-adds the editor style, which is now able to show text and scroll 
in real-time, but still has no keyboard handling yet.
-adds a few new more advanced tutorials

-adds a new demo app which is the basis for a full text-editor in 
REBOL (you can use the load button which allows you to load text 
within the editor, it loads files almost instantaneously... I was 
surprised how quickly it loaded even 1MB files), file size doesn't 
change editor refresh speed..

very extensive history of changes, 
very extensive TO DO list

some improvements to libs here and there.

------------------------------------------
GLASS Release 003 is here:
------------------------------------------
http://www.pointillistic.com/open-REBOL/moa/files/glass-r003.zip

----------------------------------------------------------
everything promised for this release has been done:
----------------------------------------------------------

-Editor style and associated text editor application (Cristoph)

http://www.pointillistic.com/open-REBOL/moa/files/tutorial-image-style.png


-Encap friendly single file version of ALL glass libs, usable just 
like if they where external files. (Graham)

-The encap version of glass is all packaged within its own .zip file 
inside the root of the distro,  to make it easier to get started.

-Image style (jocko)
-it also has a pretty cool image style demo app.

http://www.pointillistic.com/open-REBOL/moa/files/red-text-editor-v0.5.7.png

-quite a few nuts and bolts worked on here and there.

-reworked the folder structure a bit to make it cleaner (it shouldn't 
change much from now on), tell me what you think?

-Added original SVG files used to create icons as part of distribution

-Added a few reference glass-related images for demos and tutorials.

-windows have automatic title handling when you fill their labels. 
(shown in text editor)
-many libs have had their apis improved
-extensive HISTORY AND RELEASE NOTES in docs folder.

For people who likes colors......... here is updated Scintilla / 
Scite (text editor) source with rewriten and enabled REBOL lexer 
for colorized code in scintilla powered text editors.

https://github.com/Oldes/Scite/commit/cf5ef6b736553f5e6f1e8a801e91e0e3ff4b3373

Updated to correctly handle #world header detection (must add file 
extension later)... @Steeve - Scite is text editor, Scintilla is 
for color coding.. or what do you mean? Let use ann-reply

Still under 500 lines in my editor

You got script tiny : http://www.scriptiny.com/2010/02/javascript-wysiwyg-editor/
This site also provide tiny table, tony menu...

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

I never tried that, as all my .r files are associated with my code 
editor.

Also, in the editor window, hitting the  'home' key produces a null 
character, and 'end' does nothing.

Thanks.

Is tab the best choice? It's not easy/obvious how to type a tab in 
a webpage; though it's a good choice if you assume we are cutting'n'pasting 
from a text editor.

Right, the purpose was better support cut&pasting from a text editor.

I don't know. Accepting pre tags in the input (with no attributes) 
would work too, I guess. I just know that I never post code from 
a text editor into CureCode comments. Instead, it is always written 
directly or copied from the console. In neither case are there tabs 
- all spaces.

don't know if this has been discussed wrt callbacks, but it would 
be good to be able to call back into REBOL for purposes of controlling 
execution, say for debugging from a non REBOL editor/IDE

BTW: I'm going to redo the diagram using yworks yEd editor. It's 
a fantastic graph layout editor and now supports swimlane diagrams.

A frozen face does not respond to input, but is otherwise normally 
visible. A disabled face is visibly disabled. Frozen faces may not 
be necessary, but they are a first step toward creating a GUI layout 
editor.

My original DISABLED allows the face to still be rendered in a disabled 
fashion, which is good for forms. I'm not sure how useful it is to 
have your DISABLED after initial rendering, because you would actively 
have to remove the face.... although that presents some interesting 
possibilities for altering the face topology. There are already styles 
in R3 that don't render and that's handled differently.


The idea for FROZEN was that it would be a first step toward using 
the same styles with altered behavior for a GUI editor. FROZEN was 
selected, because of the simple FREEZE-FACE/THAW-FACE names.


READONLY seems the same as SELECT, but READONLY is probably a better 
name.


HIDDEN seems like a cop-out to me. :-) If you want a security measure, 
elements that a user should not see should not be included at all.


With my DISABLED, FROZEN/INACTIVE and READONLY, would that cover 
it?

Another issue is that while this should be simple to do in the dialect, 
it should also be possible to create and destroy connections during 
runtime and make it abstracted enough to be possible to do with a 
GUI editor.

focusing on the text area reveals the text-editor face
unfocusing, renders the face as described above.


but because everything is linked, the text-area face even resizes 
& moves automatically when we resize the graphic element without 
needing to unfocus it.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

one of my dream regarding the developement of applications in rebol 
was to have a way to select a bunch of your code in your text editor 
and hit run by step  to see a step by step excution of that bunch 
of code  in  order to underfstand what rebol is doing closely when 
he clone data  h

ok so then does ritch text is a really something to be set as default 
inside the VID extension or isn't it wiser to let that as a side 
project to make research about the perfect way it could be done... 
and we let in draw a set of basic commands related to draw (a revamped 
set ofcourse) for instance I think that a ritch text engine is too 
much for the syntaxe colored editor we made ... it's like taking 
a nuke bomb to kill a single little fly .... but such an engine by 
default can anyway open new perspectives. but what annoys me in the 
process is to do this  raw script -> conversion to ritch text dialect 
-> conversion to draw by the rich text engine ...  instead of doing 
this raw script text from file.r -> conversion to draw using parse. 
But maybe i'm wrong ... anyway one way or another i will do a port 
of area-tc. and i assume that if the rich text engine seems too much 
for me then i could still do my proper engine relying on the draw 
for text lower level instructions.... (not to mention i like the 
idea of learning parse through  experiements)

Robert I know that you aim to get a WisiWyg editor for makedoc Pro 
format (wich in a time i tryed to provide in a totally deferent rendering 
technology)

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

I tried to use SciTe editor to run a simple gui script: rebol [] 
 do %r3-gui.r3 view [button]

Maybe anyone has a tip how to fix this, I know this is SciTe problem, 
but I wonder whether other editor has the same problem. Thanks!

Using DOS (tested with VISTA and XP) I can launch my editor with:
>>start textpad

But how can I do that with the Rebol CALL function. It's doesn"t 
seems to work...

Or something like that - I use a different text editor.

I wonder what performance you could expect if the host was called 
for evey keystroke in the editor and was passed the complete script 
(with possible included modules) to be parsed  - do you have any 
guess? Of course the host instance would be cahced between invocations.

the module system provides enough information so that your editor 
could resolve the dependency on its own, and parse stuff accordingly.

now USING rebol as the scripting/macro language within an Editor 
 

THAT would be really cool.   :-D

but I think that the integration between the editor base and the 
lexer is too weak

trick is to find a way to parse just a subset... you might want to 
chat with steeve and shadwolf, their rebol editor was pretty responsive 
even with big files, so I guess they have an optimisation that lets 
them just token what is visible, with some form of caching for before 
and after pages of data.

I guess you might be able to do this as another type of editor plugin 
- Notepad++ has the concept of plugins that can do various higher 
level actions, but at the Scintilla level, you'd have to be mucking 
around with Scintilla code

For instance, I remember some guy named shadwolf helping resolve 
the lack of a rich text editor in REBOL :)

Graham: if you really have to write empty? vidfield/text thousands 
of times, it would probably be worth adding it as a keyboard shortcut 
in your text editor.

editor:reb.ol

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

That might not be a problem - I am a better editor than a writer.

BrianH, I will send you a R3-Module Doc after my vacation for you 
to correct. Actually, I was a technical Editor in O'Reilly Taiwan. 
Of course, The books that I edited were all in Chinese.

About the HTML parser:


This started out because we had a need for a HTML filter. The mail 
client in Qtask allows users to view HTML emails, furthermore, the 
wiki editor submits HTML to Qtask. Whenever you are embedding HTML 
from an external (untrusted) source within your HTML, you have security 
problems. For this reason, we had to take the untrusted HTML and 
1) "filter" it so that it would be safe 2) make it embeddable (eg. 
only take what's inside <body>, and not the whole <html> etc.).

So, as our needs became more complex (esp. because of the initial, 
never released version of the wiki editor), I had to change approach. 
Also, at that time Maarten was doing the S3 stuff and needed a XML 
parser as well.


So, first, the Filter was split up into three modules. The first 
is the parser, that takes a HTML or XML string and just sends "events" 
to a callback function. This can be used basically for anything. 
(Maarten never used it in the end.) The second part was the first 
FSM, the HTML normalizer. You'll still find it within the Power Mezz, 
but it's deprecated. The third part was the actual filter and regenerator 
(second FSM). You can find it in the repository history.

CSS is VERY bad at text layout.  I would not want use that model 
for a rich text editor... really it would be aggravating.

the VID editor just died on that

Brian, the only trouble with letting git do the line ending normalisation 
is that it is a bit troublesome. It's generally easier to just have 
git not touch the line endings at all and use a properly set-up editor 
instead.

Ahh.. .this is similar to the stickynotes add in for Leo, the literate 
code editor I use

I didn't realize that the word wrapping was something it did; I thought 
it was something *you* did in that message. So I put in my own line 
endings, which ended up in the wrong place because they word wrap 
at fixed indexes as if they weren't rendering with a proportional 
font. If they are word wrapping that way, they should use an editor 
with a fixed-length font and a margin line.

New editor in REBOL for Red/System : edit | compile | run for Windows, 
Linux, MacOSX !
http://www.red-chronicle.com/2011/07/new-red-editor-in-rebol.html

Make a docs directory in the rebol installation folder and type in 
REBOL console :
do http://perso.numericable.fr/frajouen/Red/editor.r

I copy/pasted it do text editor and was able to login. The code for 
GTK looks very nice

I was mostly interested in code sharing over text messages, but something 
like AltME or a code editor on my phone would be invaluable. A code 
editor that can send code snippets over SMS or other sharing services 
sounds interesting. I only mention this in this group because Red 
looks like it will end up on my phone before R3, barring a miracle.

You can use -v 6 and echo all output to a file and use a text editor 
to review the output for your code.

An alternative to ResHacker, XN Resource Editor, http://www.wilsonc.demon.co.uk/d10resourceeditor.htm
Windows only I think.

For your information: A small code editor including lua scripting 
(GTK + scintilla bindings)
All sources included.
Low c footprint.
A good inspiration for further RED evolution.
http://caladbolg.net/luadoc/textadept/manual/1_Introduction.html

AKA an aspiring RED code editor

 it is about the process of building app vs dynamic prototyping using 
 interpreter


Well, I don't know how you build apps, I have never built one from 
the console, but only from a code editor. Console is nice for testing 
some small snippets when unsure, but coding is usually done in a 
decent code editor, where you usually launch your script using a 
shortcut. From that POV, there will be no differences with Red for 
the users. And to avoid further misunderstanding, Red will have a 
console, like R2 does, with similar features and possibilities.

Doc - I use text editor too, for some complex stuff.Yet for trial 
and error I use console. Several users expressed in the past, that 
one of the nice values of R2 is its console, for the quick prototyping 
around.

How can I try topaz in Windows? Is the try-topaz.html page the only 
method? Is there a way to write a topaz program with a text editor 
and then execute it in some way?