AltME groups: search

I don't really understand why Carl can't stay connected no matter 
when he is ... it's just a question of either a laptop with roaming 
services, or, an internet cafe.  I see that the pages now have a 
[edit] link on the bottom too.

makes no difference .. file, edit or weird

Terry, cool.

Please offer bigger (taller edit window).


Just so you know. "All Rights Reserved" has no legal meaning...  
so if you are inclined, get rid of it.  IT cleans up the page.

ah, I should read first ... dunno if Rambo allows you to edit your 
submissions ...

You need edit permissions, and that applies to ALL tickets, not just 
yours, AFAIK. So I guess the answer is no.

1. click in the field and press Enter
2. press "change" button
3. click in the field and press Enter again.
In both cases, VALUE = "hello".

The reason is because ctx-text/edit-text calls the action block, 
but passes face/DATA  (not face/TEXT).

TEXT and DATA are related only at INIT and are not maintained by 
the access functions.

To be usable as part of a CGI (for dynamic sites like REBOL.org), 
we'd either need to edit the script to remove* feature* like =include; 
or (better) Makedoc2 could have some refeinements to limit where 
it can read files from.

Without something like that, features like =include are a security 
risk -- they can read anything on the server.

What would really make that MD2 IDE kewl is the ability to directly 
edit the elements in the preview pane.

Great stuff shadwolf! MDP-GUI has a good look and feel to it now. 
A couple of suggestions:


1. The preview pane is out by 40 pixels, page-width: 360 should fix 
it
2. Full-screen (even as an option) would be good
3. Option to use makedoc2.r instead of make-doc-pro.r


Now that the "proof of concept" seems sound I'll be concentrating 
on the VID emitter with a view to making it MDP complient and more 
efficient.

ability to directly edit the elements in the preview pane
 I'm working on that, but its a real pane (pardon the pun).

the rendering is slow because its a huge cheat

 - yes, like you I looked at a "live update" but its just too slowwwww. 
 An intermediate solution might be to have a timer that refreshes 
 the preview every few seconds or so.

So, I could just edit the HTML file and add it afterwards?

Did some one found a way to have a FAST Rebol editor.  I did remarked 
that the cursor is slowing to a crall on big texts in MDP-Gui.  It 
is also quite slow with VT-editor or ion-pe, or even with this very 
small editor in alt-me, the one with which I write now.  Tcl, for 
example, does have two tk texts widgets (text and C-text) to properly 
handle text.  Could there be a way to have a fast editor in Rebol, 
something that could handle a text of 100-200 pages in a manner that 
is as fluid as something like notepad.  I am a newbee and find MDP-Gui 
to be a nice course on how to play with text rendering.  Although 
I would rather have only one window, and alternate from the editing 
window to its rendered view.  Full window is nicer to write text. 
 Side by side is nicer to compare marked-up text to its rendering, 
but after a while, we know the rendering and simply want the fuss 
a a nicely rendered text.  I am fidling with this idea, but do stumble 
on the editor part.  I dont even know who is the culprit, area or 
the ctx-edit.  If someone has a simple solution to this, he should 
post it.

1- caret repositioning in a big text and 2- rendering text in the 
same window that we edit

will be to settle it by inverting the problem : edit text in a console 
or an editor, and have the console or editor to parse the text and 
transform it according to the commands it find in it.  I did search 
for that.  The closest library to such goal I found is either scintilla 
for an editor or tkcon, the adaptable tcl console.  But all this 
suppose that we dispose of Rebol source code to put the language 
parser in it, right (like ion.pe)?  So we would have to rely on R# 
(open source) instead of Rebol?  Either way, it does seem that handling 
the problem well is pushing us out of Rebol; not a charming proposition. 
 I am just expressing my frustration of not being able to solve a 
problem that is not existing in other languages.  As a priority, 
I do think that the repositioning of the caret is the show stopper. 
   I could live with NOT rendering in the SAME window as the editing 
window; I consider it a form of cosmetics.  But I can hardly ask 
people to start edit documents in a lame editor that takes seconds 
to go from page 120 to 130.   It would be nice if RT could find a 
solution to that, as it would ease the way to specialised IDE's, 
Ide for Rebol and the many specialised dialects.  By the way, did 
Ammon Johnson finished to wrote his REBOL-based IDE, called RIDE?

I would like to create an IOS Wiki application based on MDP syntax. 
So it should be a Wiki I can use as IOS user and browse / edit with 
some kind of editor. Here are some thoughts (unstructured). I'm looking 
forward for you comments.

1.) How to handle CamelCase links and content?
	- One approach is to create a TXT file for each CamelCase word.
	- Than new files need to be autoadded to the fileset or

 - The editor recognizes CamelCase words and creates new files, this 
 implies the the internal
	  editor is used.


2) MDP needs to be extended to translate CamelCase words into links 
that MDViewer can handle


3) Filesync clashing needs to be integrated into IOS with DIFF/MERGE 
option based on the synced TXT files

you edit in work-folder and when done publish to the public folder. 
with some reblet which shows you which files you changed, and maybe 
checks links.

To Brian's comments on Make-doc.  I've tried using it as well.  I 
found it was great for short documents and started to get hard to 
us as we moved to larger documents.  i shouldn't say hard to use, 
but hard to edit the document once I made changes or stumbled across 
errors in the original.  I should have used 'find' more, as it really 
was difficult to scroll around and find where you were in a larger 
documents.  Has anyone else experienced the same thing?

Graham, Thanks for the reply...I've been working on the house so 
my computer has been down for a few days...anyway:

I have found some utilites to extract images and text but I'm building 
a tool in rebol to coordinate the conversion of pdf's to text and 
extracted images, to edit them, and to upload. I was hopig for a 
rebol solution to incorporate it all into one app. The tool will 
be used by non-tech so I wanted it simple as possible.

How do these extaction utilities work? Are they no parsing out the 
image data?

it's possible to edit the pdf file by appending stuff to it, but 
you'll need to read the specs to make that work, it's not entirely 
trivial either.

if you say guys you hav a powerfull Sclar and Vectorial dialect in 
rebol but you have to take you text editor to compose you graphics 
those guys will trash out out the window ... You can expect a guy 
the use all along the day photoshop illustratior, Wave etc to open 
a text editor there is no way !!! Like to expect that a 3D modeler 
will let apart his grpahical environement and use a taxte editor 
to make his 3D scene and animation usin yafray or povRAY... Script 
3D renderer are far away from in realtime 3D workbench (with graphical 
UI) but what want a 3D worker ??? Take 3 weeks to write a scene then 
wait three weeks to have the rendering then make the constatation 
that the result is not exactly what he wants and restart for 2 weeks 
of work and 3 weeks of generation ? Or edit his scene into a graphical 
UI that allow him to moselise and renderise his work in a bench of 
seconds ?

I use CE as well, but often switch to use View editor to edit ftp 
files

Requesting Opinions.  Being a crusty old forther, I really really 
miss the immersive nature of the block editor environment.  Coding 
in forth meant never leaving forth.  Editor, debugger, disk drivers 
etc... all forth commands.  No need to ever have the brain exit forth 
mode.  Now that Rebol is my language of the future, I kinda pine 
for the past.  The wonder and beauty of Rebol keeps being interrupted 
by decisions on what to use to edit that last little bit of script. 
 Notepad, Crimson Editor, Rebol editor? A small annoyance but it 
still disrupts the brain from getting to streaming mode.  So now 
to the question.  My first crack at a forth block editor dialect 
failed miserably.  Dialects need to be LOADable for parse to function. 
 Editing source code makes for unloadable situations.  Do I just 
give up on it and learn to live in the third millenium?  Write a 
utility that doesn't use dialects (which seems to unRebol the solution)? 
 I thought I'd ask you guys, just in case there is a light shining 
in front of me that I can't see.  Thanks in advance.

Well, I've never gone Forth, and I'm not sure what a block editor 
is, but maybe you can benefit from some console commands. I almost 
always use Crimson Editor. I have an EDIT command which launches 
Crimson Editor, and I navigate the filesystem in the rebol console 
using dir-utils.r, which supplies unix-like filesystem commands; 
CD, LS, MV etc.
http://anton.wildit.net.au/rebol/os/windows/edit.r
http://anton.wildit.net.au/rebol/library/dir-utils.r

I am not sure where your focus is.
Editor-dialect: put the edited code in strings, like
[ #1 {io-code} #2 {gui}]

Patch the inbuild editor to load and store there, instead iof storing 
to files.

And from the console a simple "ed #2" would edit it. but still in 
a seperate window.

Console: Or is it about that seperate window, do you want inside 
that rebol-console-window? More work, but rem-edit does that, maybe 
its author would help with fixing.

Obviously people who do code golf come to it from different perspectives, 
I think Rebol's key here is just to engage by giving lively and flexible 
solutions which pique interest.  I intentionally didn't clone the 
deranged "winner" of the roman numeral contest because he'd thrown 
out the program logic, it was no longer source code.  I can edit, 
debug, and insert probe messages into mine easily.

as in linux you have a http.conf file to edit

Francois - I accept your explanation of Magic's concept only in the 
case, if designer can upload different template without me (the developer) 
needing to edit it .... but I may be not so strict :-) I will look 
into Magic's english docs - french docs are really a problem for 
me ...

With QM, I use QuickTags (integrated into RSP or standalone) to build 
the form elements, and then wrap common constructs in functions.for 
data-driven forms.  It's not as pure as say, Henrik's HTML dialect, 
but perhaps has the flexibility of being at markup level.

http://www.ross-gill.com/page/QuickTags


Alternatively I have a make-doc dialect (somewhat rough) that I use 
for forms on my site wiki.

http://2008.rebolconf.info/on/!Edit_Form?format=raw

Just don't use Frontpage. If you end up having to edit the pages 
later by hand, it's faster simply to build them by hand.

I recently used Kompozer to build a quick site to fix a friend's 
site that was so bad I figured I could at least spend a few hours 
and take it from a 1 to a 6 (scale one to ten).

There are a few variations of Kompozer.  But Kompozer is the best 
of them.


It still sucks though.  When you do view source it does not put your 
cursor where you expect it to.  It is nightmarish to figure out how 
to edit tables. 
But, over all, if you keep things simple, it works well enough.

mobile browsing expected to outpace desktop access in 3-5 years.

Most of the world lives on their cell phones.


As to JavaScript Frameworks to fix the biggest human fail in computer 
history (that being that we use HTML+JavaScript to build UserInterface), 
having headed the creation of a complete UI system that is delivered 
through the web, I will say the following:


- Find something that handles Tables (grids, lists) well.  Make sure 
it does verything you need.

- Make a list for yourself of widgets you care about, and confirm 
(assume nothing) about the level of detail with which they operate. 
 For example, Imagine 3 radio buttons, on the web they have no default 
state, and some interfaces allow them to operate like checkboxes, 
not radio buttons.  Again, assume nothing!

- Confirm, for yourself, they work on the platforms you care about. 
 Nothing works on everything, even when they claim it.


I did not want to build Quilt, but we still don't know anything that 
comes close other than Tibco's crap, and I'm not sure they even sell 
it anymore. (I recall it was like $100K).

finally got an editor with find/replace/plugins working (at least 
for me ;) http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=install-edit-tools.r

New editor that support REBOL  colored syntax file. This sofware 
is SCITE 1.66 for linux and windows by default REBOL support is not 
activated. edit /usr/share/scite/ScitEGlobal.properties file ( MenuBar 
Options >  Open Global options File) search the line "#import rebol.porperties" 
and remove "#". Save changes (SCITE must be launched from a root 
terminal.) then edit /usr/src/rebol.properties file. Go to the last 
line of this file and set the proper path to your predered rebol 
VM version in the  command.go.($file.patterns.rebol)=....  Save the 
rebol.properties file ( this file can be located from Menubar Options>Edit 
properties>open rebol.properties). Once you make all those changes 
you are able to see rebol color syntax for your beloved rebol scripts.

the scripts are launched into the rebol VM hitting F5 key in SCITE. 
You will notice that the color syntaxe is very more advanced than 
the Crimson Editor one. And you have the  ability to hide the functions/objects 
inside code to make easier to read the script code.

Well this is the concret sign that REBOL  is being more and more 
considered in computing world. This is a good thing and a good reward 
for RT hard work.

For anyone interested ... I have hacked an update to clip.r to the 
edit facility to allow removal of persistent clips that are no longer 
required.

Visit  http://www.TGD-Consulting.de/Download.htmland take a look 
at

the final release of Hex-It!. (I posted on behalf of Dirk Weyand, 
since he cannot reach AltME)


Hex-It! is a small but powerful hex-editor. You can use this tool 
to analyse
or alter the "fingerprints" for any kind of files.

Known first as a contribution to the REBOL Demo 2006 contest, the 
final
release with enhanced features is available now.
Features of Hex-It! v1.2.0:
---------------------------
* cross platform hex-editor

* free "save-feature" for small files sized lesser 15 KB, to edit 
larger
  files purchase a license-key that unlocks this limitation
* enhanced spot navigation with mouse scroll-wheel support
* non blocking file access 

* support of large files (a maximum chunk of 1MB file-data is only 
held in
  memory at once)
Some notes and useful tips & tricks on the usage of Hex-It!:
------------------------------------------------------------

- Modifications of files were automatically saved on exit, if you 
load

another file or if a different chunk of the same file is selected.
- Byte selection:

  + Select a byte with a left mouse button (LMB) click on the hexadecimal
    values to the left. The byte is highlighted then.

  + If a byte is selected, either use the cursor keys or the scroll-wheel 
  of
    the mouse to scroll through the bytes of the file.

  + Change a selected byte with plus (+) & minus (-) or just enter 
  its

    new value. Single characters, three digit numbers or single hexadecimal
    values are valid.

  + Use the right mouse button (RMB) to deselect a highlighted byte.
- Spot-navigation:

  + The spot specifies the index/position of a byte in the file. If 
  no byte

    is selected it shows the position of the top left byte displayed. 
  + Enter a number to set directly the spot to a byte-position.

  + Skip a certain amount of bytes relative to the current spot by 
  using

    plus (+) & minus (-), e.g. "+10000" skips 10000 bytes forward and
    "-1000" skips 1000 bytes backwards. 

  + Skip to end of file: Click with the RMB on the arrow-down Spot-button
    or use the "End"-Key.

  + Skip to first byte of file: Click with the RMB on the arrow-up
    Spot-button or use the "Home"-Key. 
- Seek:
  + ASCII- or Hex-Strings are valid queries.

  + LMB click on the "Seek"-button seeks from the current position.

  + RMB click on the "Seek"-button seeks from the beginning of the 
  file.

Please note, that the license of this release is not BSD like anymore.

you can edit these to rip out the stuff you don't need.

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

Luisc: It's on the ToDo list. From the release notes above:

	Known issues
		...
		- edit-list needs auto-fill logic added

Could you make the drop-list - with the auto-fill too? even if it's 
not editable.  Would make easier to find a value.
 I think he is really talking about drop-list not edit-list ...

and no i am not talking about an edit-list. And is not an auto-fill 
per se routine. More like a keystroke capture routine so that it 
would do a search on the list  = )

Luisc we have 2 item in fact edit-list to handle large data with 
some useful stuf like list vertical scroller and auto-fill field 
This is what you want. And the drop -list widget that is for handle 
tinny list of data :)

I've been checking out RebGUI.  A number of very good design decisions 
were made.  I've ported my pair-edit style to be rebgui widget.
http://www.lexicon.net/antonr/rebol/rebgui/demo-pair-edit.r
(It needs editing to locate your rebgui directory.)

Anton

 1) Design decisions: thanks; if you think any of them were *bad* 
 then let me know, that's the reason it's still alpha ;)

 2) I like the edit-pair demo, I'll look at adding a cut-down version 
 of it to %tour.r

 3) Versioning / caching was something I was going to look at once 
 RebGUI goes beta and / or we have more of a handle on how REBOL/Services 
 works.
	4) "local" face definition: good point, added to next build.

 5) Extending widgets object: Yes, RebGUI doesn't have a "stylize" 
 system so you have to extend the widgets object when you need to 
 add your own. My hope is that with a functionally rich set of widgets 
 this will be the exception rather than the rule!

Robert

 Action handler not yet added to table widget. I'll add odd/even coloring 
 to the ToDo list.

Volker

 [face value] - less important for RebGUI as face/text or face/data 
 covers almost all cases; but I'll think on it a bit more as the compatibility 
 aspect is worth considering.
	/init - I'll look at making this a block in the next build.

 event-func removal - I'm considering a "load-time-flag" as you suggested
	system/standard/face - as per comments to Anton above
	"If there is ..." - agree fully with everything stated here ;)


RebGUI development is taking a slight pause until View 1.3 is released, 
as I want to baseline against that and remove all the pre-1.3 exceptions 
that have crept in.

Ashley, I had also wrote a VID integer-edit style, then I decided 
to make a single function to generate pair, integer and decimal-edit 
styles. I could convert this in future. It kind of violates your 
"each widget self-contained" design feature, but the code shrinkage 
was too hard to resist, and the potential is there to support more 
datatypes...

... simplest widget ever ...
 How much is there to write about?

	widgets: make widgets [my-widget: make face []]

Or am I missing something? ;)


Your VID edit styles sound interesting, but I'm looking for a more 
universal solution to "field input masks" and "field input validation". 
Something that would let me define a telephone number mask for example.

Latest build available at: http://www.dobeash.com/files/RebGUI-024.zip

Highlights include:


 - New edit object / feel added in a separate file, %rebgui-edit.r

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html
	- Face redefinition localised to widgets object
	- Radio-group color toned down from green to leaf

Known issues:

	- auto-fill broken for the time being

 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- inline spell-checker

Here's another issue:
rebgui 0.2.4 defines a new global word 'edit

  This interfered with my custom edit function, which I use to launch 
  my favourite editor.
  I'm not changing it for you ! :)

  This is an example of the problem of adding words to the global context 
  without doing
  an environmental impact study first.

  The user should be given the choice whether to export your words 
  to the global context or not.
  But probably most of them don't need to be out there at all.

  My advice is to add only these words to the global context: [

 ctx-rebgui display show-text show-data show-title splash request-color 
 request-date request-file
  ]
  
  --- rebgui.r ---
  
	CTX-REBGUI: context [

		...

		edit: none
		widgets: none
		requestors: none
		display: none

		foreach [word file][
			edit		%rebgui-edit.r
			widgets		%rebgui-widgets.r
			requestors	%rebgui-requestors.r
			display		%rebgui-display.r
		][
			if none? word [set word do file]
		]
	]

	;if not value? 'edit [do %rebgui-edit.r]
	;if not value? 'widgets [do %rebgui-widgets.r]
	;if not value? 'requestors [do %rebgui-requestors.r]
	;if not value? 'display [do %rebgui-display.r]

	; export DISPLAY and the accessor functions to global context
	foreach word [display show-text show-data show-title splash][
		set word get in ctx-rebgui word
	]


  And each file no longer has a *named* context:

  --- edit.r ---

	REBOL [...]
	
	context [...]


  The above changes should mean few changes to the rebgui code. For 
  example, the body

  of the display function refers to the widgets context, but this is 
  still accessible
  because both DISPLAY and WIDGETS are inside ctx-rebgui.

The words I don't think need to be global are: [sld slm slc slw edit 
widgets requestors]
(and even the ones I have set out above I would scrutinize more.)

edit:
#include %edit.r

I think this may work (not sure, can't test):
sdk?: is-this-sdk? ; <--- need to find out a real flag

set 'edit	do #either [sdk?][#include %rebgui-edit.r][%reb-gui-edit.r]

set 'widgets	do #either [sdk?][#include %rebgui-widgets.r][%rebgui-widgets.r]

set 'requestors do #either [sdk?][#include %rebgui-requestors.r][%rebgui-requestors.r]

set 'display	do #either [sdk?][#include %rebgui-display.r][%rebgui-display.r]

CTX-REBGUI: context [

	...

	edit: none
	widgets: none
	requestors: none
	display: none
		
	#do [edit: do #include %rebgui-edit.r]
	if none? edit [edit: do %rebgui-edit.r]
	#do [widgets: do #include %rebgui-widgets.r]
	if none? widgets [widgets: do %rebgui-widgets.r]
	#do [requestors: do #include %rebgui-requestors.r]
	if none? requestors [requestors: do %rebgui-requestors.r]
	#do [display: do #include %rebgui-display.r]
	if none? display [display: do %rebgui-display.r]
	...

]


CTX-REBGUI: context [

	...

	edit: none
	widgets: none
	requestors: none
	display: none
		
	smart-do: func ["helper function to reduce repetition"
		ignored [issue!] block [block!]
	][
		if none? get first block [do replace copy block [#include][]]
	]
	smart-do #do [edit: do #include %rebgui-edit.r]
	smart-do #do [widgets: do #include %rebgui-widgets.r]
	smart-do #do [requestors: do #include %rebgui-requestors.r]
	smart-do #do [display: do #include %rebgui-display.r]
	...

]

Ashley, you found the issue way too. :) Chris' function looks very 
good.
Here's another way:

 edit: do either any [#do [false]] [%rebgui-edit.r][#include %rebgui-edit.r] 
 ; (false is actually not needed)

I eventually solved it with:

	ctx-rebgui: context [
		...
		edit: #include %rebgui-edit.r
		if issue? edit [edit: do bind load %rebgui-edit.r 'self]
		...
	]

it's two lines as opposed to one, but *much* clearer! ;)

Ashley, I was trying to reduce the number of variable references, 
eg. in my last (possible) way, there is one instance of EDIT and 
two instances of the filename. In your last way, there are three 
instances of EDIT, and two instances of the filename. Anyway, I agree 
it's easier to understand.

Fixed the problem (disappearing label text after a field scroll) 
that Colin identified. Just needed to change "para: default-para" 
to "para: make default-para []" for editable widgets (as the new 
edit feel changes "para/scroll" values).

I agree on 'drop-list / 'edit-list usability problem : the list should 
be at least closeable when clicking on the arrow button again - escape 
key isn't enough, as it's a mouse driven GUI.

Graham: RebGUI encap needs:
	#include %gfx-colors.r
	#include %gfx-funcs.r
I've added these to the next build.


Pekr: I've updated the choose func (used by drop-list / edit-list) 
to issue a hide-popup when the mouse leaves it. Feels pretty intuitive 
to me, but I'll see what folks think once the next build is out. 
;)

Vincent: Agree, I'll see about adding that for 0.3.0 as well.

Excellent! Just tried it with RebGUI and it works beautifully; even 
with global events killed. I think the edit-list / drop-list problem 
is solved. ;)

Latest build available at: http://www.dobeash.com/files/RebGUI-030.zip


*** Note that this version requires View 1.2.124 or later, and that 
the zip file is unusually large (346Kb) as it includes a dictionary 
file (future builds wont). ***

Highlights include:

	- New language, dictionary and spellcheck functionality added

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html#section-4
	- All objects merged into one context
	- Major code reorganization / restructure
	- Reduced number of global words to 11
	- Pre-0.3.0 comments removed
	- Pre View 1.2.124 code removed
	- New text-list widget added
	- Added show-color accessor function

 - rebface and rebfocus synonyms to avoid collision with face / focus
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/roadmap.htmlupdated

Known issues:


 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)
	- focus

 - edit-list / drop-list should use show-popup/away (some compatibility 
 problems)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- menu widget
	- better keyboard navigation / focus

If you drop down the edit list, and then edit the field,  the list 
won't collapse again.

http://www.dobeash.com/it/rebgui/edit.html#section-4

The dictionary, if present, is then loaded into the dict block.

anton: Can you take a look at the autocomplete style for me, after 
doing pair-edit you will be more in tune than me.

I think the default behaviour for a tab within an edit-list should 
be to leave the list, and not insert a tab.

inkskape edit very well the set of icons you provided with svg-demo.r 
;)

do %rebgui.r
display "RebGuiTest" compose/deep/only [
        label "Query" t: text 40 "" return
		a: area 100x50 "In the beginning, "
        button "Insert" [
				insert a/text "Title{}"
				; edit-text a enter

    insert tail a/text "And from a barely documented VID, a need for 
    something bare but easy to document: RebGui.  And the user saw it 
    was good."
				; edit-text a enter
				show a
        ]

do [at face/pane/3/text 10 insert tail face/pane/3/text "there was 
View 1.3.  "]
] ; End Display
do-events

How to move the cursor to inside the brackets of Title{->Here<-}.

How to enter a newline, and more generally use the function defined 
in rebgui-edit.r into the area?
** Script Error: edit-text has no value
** Where: action
** Near: edit-text a enter

More generally, how to enter a string and move the cursor after the 
insertion of it.  Thanks for an answer to this 'II am New' question 
pertaining to RebGui.

This should get you going:

display "Test" [
	a: area 100x50 "Title {}"
	do [
		rebfocus a
		system/view/caret: back system/view/caret
		show a
	]
]


The RebGUI edit-text function (and indeed the majority of the edit 
context) is designed to be used from within RebGUI widgets ... it's 
not "user-space" functionality. Manipulating text and / or focus 
is done via the standard view mechanisms (system/view/caret, focal-face, 
highlight-start & highlight-end) ... RebGUI just provides an encapsulated 
front-end to these. Depending on what sort of operations need to 
be performed (e.g. move the cursor to the Nth character), we can 
certainly add additional user-space functions (much like rebfocus), 
we just need to define what these functions are and how common their 
use would be.

** Script Error: white has no value
** Where: context
** Near: edit: white
over: gold
menu:
** Press enter to quit...

Error message when running tour.r with the new encap.

Occurring here ...

	colors: make object! [
		window:		236.233.216		; used by display.r
		widget:		244.243.238
;		widget:		248.248.248
		edge:		127.157.185
		edit:		white			; area, field, password, etc
		over:		gold			; active button, tab, splitter, etc
		menu:		49.106.197		; menu, popup highlight
		btn-up:		200.214.251
		btn-down:	216.232.255
		btn-text:	77.97.133
	]

Place the text cursor in the edit-list widget, and then press tab.

Isn't localization wonderful? ;)  [just edit / delete %locale.dat 
to "fix"]

Latest build available at: http://www.dobeash.com/files/RebGUI-034.zip


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:

	- request-dir requestor updated
	- alert and question requestors added

 - Tab focus expanded to include edit-list handling (see %focus-demo.r 
 for details)
	- Button image now resizes correctly

 - text-list widget totally rewritten to use [newly documented] View 
 1.3.1 iterated faces
	- text-list now supports Ctrl+click, Shift+click, Ctrl+A

 - text-list scrollbar now reacts to current display state (eg. disappears 
 if not required, alters dragger ratio as rows are added, etc) 
	- check and radio widget aesthetics improved

 - added options support to layout function and text-list and check 
 widgets

 - changed base-size from 4x5pixels to 5x4 pixels (better granularity)
	- reworked all widget sizes to account for above
	- fixed scaling problems with many widgets
	- updated focus-demo.r

 - greatly enhanced and expanded %tour.r to demonstrate more variations 
 and usage cases
	- added "live" unit-size and font-size drop-lists to %tour.r
	- numerous other minor bug fixes and coding improvements

In the works


 - table widget being rewritten along the same lines as the new improved 
 text-list widget
	- aiming for a 0.4.0 beta release prior to DevCon2005

** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:
** Press enter to quit...

on tabbing out of an edit box.

With the text in an edit list highlited, click on the drop down arrow, 
click on a new item, then tab .. and the above occurs.

If you type enough text to start text scrolling, this is what happens


>> display "" [ myfield: field 20 [show-text face now/time/precise 
print face/text] ] do-events
16:50:17.808
** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:

Latest build available at: http://www.dobeash.com/files/RebGUI-035.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:


 - generic face-iterator function shared by all lists (text-list, 
 table, edit-list & drop-list)

 - new improved table widget finally supporting row (including multiple) 
 selection

 - updated drop-list & edit-list widgets (defocusing support still 
 limited though)
	- area widget now sports a slider by default

 - resizing code (supporting negative sizes) reverted to pre-0.3.4

 - IMPORTANT: resizeable windows that don't have min-size specified 
 are automatically assigned one the same as the original window size
	- Various multi-row text selection issues resolved
	- Various focus issues resolved
	- numerous other minor bug fixes and coding improvements

In the works

	- basic menu widget
	- revamped documentation 
	- stabilize existing code-base for 0.4.0 beta release

display "" [ group-box 60x20 "Test" data [ a: field 40 [ show-focus 
f]] return group-box 60x20 "Test2" data
[ f: field 40 ]] do-events
** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:


After typing a few times in the top field, and then hitting enter, 
the error above can occur.

display "" [ group-box 60x20 "Test" data [ a: field 40 [ show-focus 
f]] return group-box 60x20 "Test2" data
[ f: field 40 ]] do-events


type abcd in the top field, hit enter.  Type abc in the bottom field, 
and hit enter.  Then hilite all the chars in the top field, enter 
a single character, and hit enter.  

** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if all [tmp/x < 0 tmp2/x < 0] [face/para/scroll/x: tmp2/x 
- tmp/x]
tmp3:
>>

This is version 3.6

No plans with 'get-text, unless it was to do something over and above 
what face/text does (i.e. trim then show).


The alert problem is related to RebGUI's liberal use of hide-popup 
to cope with drop-lists and edit-lists that need to be closed when 
another one is opened. I figured at the time that having more than 
one non-modal dialog open at the same time probably didn't make much 
sense - although an alert from within one is a valid case [in hindsight].

Note the following user-configurable blocks under ctx-rebgui/edit:

	tabbed: [area field edit-list password button]

	hilight-on-focus: [field edit-list]

	caret-on-focus: [area field edit-list password]

	action-on-enter: [field edit-list password]


But its probably a good idea to agree on the "correct" default behaviour 
anyway.

redraw: func [face act pos][

        if all [act = 'show face/text-y <> second size-text face] [
            face/text-y: second size-text face 

            face/pane/ratio: face/parent-face/size/y / face/text-y 

            unless face/pane/ratio < 1 [face/para/scroll/y: 0 edit/focus face]
        ]
    ]

** Script Error: Invalid argument: redraw
** Where: context
** Near: feel: make edit/feel [
    redraw: func [face act pos] [

        if all [act = 'show face/text-y <> second size-text face] [
            face/text-y: second size-text face

            face/pane/ratio: face/parent-face/size/y / face/text-y

            unless face/pane/ratio < 1 [face/para/scroll/y: 0 edit/focus face]
        ]
    ]
]
esc:

I only changed rebgui-edit.r so far.

changed rebgui-edit end rebgui-widgets (area there). my usual change-mark 
is ";?", search for that.

edit.html#section-2.5 :  edit/focus works only if i refer to it as 
ctx-rebgui/edit/focus

edit-list does not display past the border of a drop-list.

And if you are using the Uniserve from the link above, you should 
know, that it's just a shapshot from doc's folder so you have to 
for example edit some files - for example the default prefs of the 
HTTPd as they are leading into files which don't exists.

just go to services/HTTPd.r file and edit the prefs

This is a very small VPS, but I have 300kb raw rebol data structures 
in ordinary files, and I edit and seek them without any indexes and 
it works immediatelly..  I only moved this part of data to sqlite 
because it handeles the file locking ( these are sort of mailboxes 
so that the app and bots can communicate over them )

I have a button "Edit" which imperfectly shows you the dialect source 
( strings lose their quote marks).  Not formatted though.  And save 
which is supposed to re-render any changes doesn't work .. because 
the data needs to be converted from text to a block, and without 
the quote marks for the text, it dies.  Too late for me to find a 
fix.

Yeah, "Edit data" just forms the data, mold it instead.

you can edit and save, and it redraws it.

If you use the "edit data" button, and change the word "justify" 
to "left", and save, the text reappears without the full justification.

so I think there should be an option to leave that out, or by default 
not have it. I'm guessing most people want to generate and print 
PS file, rather than read and edit them by hand.

To do anything about it, we need to be able to reproduce that error, 
and see if we can figure out, that might solve it. A way to test 
different things is to edit the ps-files by hand.

For example, from this url: http://foo.com/pages/edit/1-- I get 
the Request_Uri value "/pages/edit/1" then parse it -- ["pages" "edit" 
"1"] -- here I have a controller, and action and an id.  It is a 
more enduring approach than http://foo.com/cgi-bin/qm.r?controller=pages&action=edit&id=1

That's because the DEBUG mode is activated by default in these beta 
releases. To get ride of it, just edit the httpd.cfg file , find 
the webapp "/testapp" option block and remove the 'debug keyword 
 (then restart the server).

Or, do I edit cheyenne.r to do that?

Pekr, you have an issue with your localhost DNS resolution. You should 
check that your hosts file is not messed up. If you can fix the localhost 
problem, here's a workaround, in Cheyenne archive, edit the mods/mod-fastcgi.r 
file, find the fastcgi://localhost:9999 expression and replace it 
by : fastcgi://127.0.0.1:9999, that should work.

To enable the PHP support: edit the %httpd.cfg config file, uncomment 
the indicated section and change the path to the php-cgi binary, 
that's all. The new mod-extapp will launch and kill PHP for you.

The web control panel purpose is to provide an embedded UI for managing 
Cheyenne configuration. Once done, you shouldn't need to edit the 
httpd.cfg file anymore.

rebol would be very interesting  choice for this because it can "do" 
and process it's own code at runtime and it would make for a *dream 
combination* of making games that you can code and edit at runtime 
without restarting!

Very interesting. I was burned too few times with GUI based tools 
with no simple representation taht you could programatically or by 
hand edit also.