AltME groups: search

still, wouldn't it be a good approach? the rate could be once per 
hour, plus on demand updating

this way, if you really want realtime, it's a matter of adjusting 
the rate

still, it would be a good demo :)

I'd love to see a demo of an overview of graphs updated in realtime 
from any source. any.

well for starters Rebol, but what if you could mix data like that 
and then just display it, no matter if it's CVS, rebol blocks or 
something measured off the serial port from a physical device.

sounds like you want to make a rebol oscilloscope

actually I think the hardest part would be to display a pretty graph 
:-) retrieving data could be done from within the graph face

graham: an oscilloscope could be a bit too intensive :-)

It could be nice to have general graphing tools for Rebol like RRDTool 
which is a very powerful (but complex) graphing package for Linux

A start:

Picking data online and show a graph could maybe be an one-liner. 
:-)
Only with REBOL! (TM)

I guess so. Isn't a dot on a monitor a very small circle? Just change 
radius to 1 or 0.5 or something.

a dot on my monitor is a little square :)

:-) A one-pixel dot:

Looking carefully at my laptop screen, it's a grid of square pixels.

The translate move the center of the circle into the middle of a 
pixel. Radius of 0.5 then means, the circle won't go into neighbour 
pixels.

Perhaps you can incorporate a graphing module in Canvas :)

you could do really weird stuff with that. how about live graphs 
in a presentation?

There is a window face option named "all-over", that will "Causes 
the over event to report a continuous stream of mouse positions as 
the mouse moves over the face". I use it in Canvas, but there seem 
to be a problem. After a while, when I haven't touched the computer 
for some time, it seems, that the all-over option is canceled. It 
can be seen in Canvas, that the coords in the title-bar isn't updated, 
when the mouse is moved.

Does anyone know something about this? I've checked RAMBO, but couldn't 
find anything about it.

I unsuccessfully tried to install View 1.3 under Windows/XP on a 
multi-user machine. It is only accessible from the administrator 
account under which the installer was run. It is not visible in the 
All Programs Start menu for others users. I can run it by browsing 
through to the underlying Rebol folder.


Does this mean that I have to manually insert it into the Start menu 
of other users ?

try to install it again from a user-account.

it shares then the readonly-files from the admins installation (exe 
etc), but uses a file in the users account for the others (public 
cache etc)

That is far from being a good aproach - in fact, it sucks ...

I understand why it was done in a way it was done though. Installing 
for all users would require at least power-user access, which typical 
user does not have, at least in corporate environment, while at home 
I expect most ppl run as administrators,  although it is not wise 
idea, but it is how typical WinXP install happens ...

Petr: I would be happy with the standard installer fully installing/fully 
removing for all users on a machine but then I only have two machines 
to worry about. The nuisance for me is that View partially installs 
for all users.

I know that I just have to copy the "shortcut" from the insatller's 
startup\programs folder to all user's startup\programs folder but 
it's a pain.

It seems that if View is installed on a XP machine that it is always 
available to every user account on the machine - it just may not 
 be visible on the desktop or through the desktop.

this is true, im using nsis to install rebol and run a custom script, 
some times rebol still pops the desktop, but i've found it to be 
better and clear tan rebol one's, .r asociations are made by nsis 
(on the script, not too hard) te uninstal is even better, a nice 
solution. until i get the Rebol SDK....

is it possible to affect the key repeat rate? I'm trying to read 
a magnetic card through a reader which delivers one char at a time. 
I'm reading it into a face which has a feel that reads each key event. 
But the keys are read very slowly, about at the maximum key repeat 
rate set by the OS, so it takes 5-10 seconds to read a card with 
only 116 chars. Is there a different way to do this or can I manipulate 
the key repeat rate for that face?

I don't have access to a library interface.... it would probably 
need to be redesigned with a different approach... in earlier tests 
I used the console with ASK which was plenty fast enough.

oh well it seems it won't be a problem after all, just that OSX Rebol 
seems to limit keyboard input somewhat

then maybe report your findings in OS-X group here or even RAMBO? 
Dunno if it is a bug or not ...

what's the correct way to access face data from within an effect 
block? I would like to scale an effect with a face as I resize it... 
or will I need to re-initialize the effect block on every resize?

i guess effect-block does a limited version of reduce now. then you 
could put things in words and that words in the effect-block.

I have a system tray dialect in the script library - %simple-system-tray.r 
- if it's helpful.

again :-) two questions:

1. if I use word-browser and evaluate an example, a rebol command 
promt will open (usually) and show the example .... shouldn't it 
be possible to close this example prompt window without closing the 
word-browser as well .... maybe this is just a problem on my system 
- I don't know

2. certain programs on viewtop close immediately after starting them 
or some part - eg. Canvas.r or also under viewtop in the Rebol Tools 
folder Rebol Logo, DL or Icon Maker .... on the command prompt with 
canvas.r one can see that the programs return immediately instead 
of staying in the event-loop and when typing again 'do-events it 
returns immediately as well


I tried now the current view 1.3.1d and there happens the same in 
my system. Has anybody an idea ?

2. Look very strange. Have a look to your %user.r and %rebol.r file 
to see if there is not something hiden there.

Volker: what I think it should be like is, that you have during coding 
always the word-browser open and if we have the option to evaluate 
the examples by mouse-click we do so .... but do this a couple of 
times and you have a window mess, so closing them seams natural, 
doesn't it ? :-)

no, it must. its the "rescue the programmer"-window. if something 
goes mad, close this window, phew. thats why debug-scripts have always 
a print "console" on top.

well, I still don't like it as somehow this is a kind of hidden connection 
which one doesn't expect - kind of "if something is on the screen 
it should be obvious what's going to happen if I do this or that" 
:-)

might make sense, at least according to the principle I meant above


actually I think it really wouldn't be that simple, because it is 
only one process and as you mentioned above it's a console-window 
and the only windows I know which would be closeable easily are view 
windows and the console seams to be none in this sense

The ability to evaluate code examples in the word browser was done 
without inserting a "proxy" print statement, or probe, or others, 
and the code examples were not updated either. It's a bad solution 
for now; just a first step.

Yes, that might work Volker. The first thing to do is make all the 
code examples consistent and define the standard for how to write 
them, so we know which "output channels" we need to handle. e.g. 
Carl put in a proxy for the VIEW function, so examples that use it 
would do a VIEW/NEW automatically.

another thing to add would be: a shortcut to get always quick back 
into the search field (like just press #"s") - if it's not yet there

Yes, but we don't want every example popping up a new window. I think 
it's better to limit examples to using PRINT and catch that to display 
in an output field of some kind, probably along with the code that 
generated it; a simulated, read-only, console.

Purpose: {Mimic DO EVENT (which is called in wake-event) with a mezzanine 
function of our own.
	The mimicry is good for two things:
	1) as a document of how DO EVENT works inside

 2) as a way of achieving crazy magical tricks not otherwise possible, 
 like 
	   - faces transparent to events

    - restoring and saving facets of iterated faces before and after 
    events are sent to them 
	     (see shell-list.r)
}

Currently shell-list, with the help of mimic-do-event, is iterating 
buttons and toggles, and they operate just like standalone buttons 
and toggles. If you've tried putting buttons and toggles in a list 
you know it is not easy to achieve.

I've just submitted a patch to RAMBO which should allow progress, 
slider and scroller to also be iterated without problems.

Brock, just try iterating scrollers (changing face/data on each iteration) 
and you see that it is much better this way. :)

This patch doesn't try to do everything, but makes a small step to 
ease iteration.

Having said that, I discovered that my patches show visual artefacts 
when resizing under other scrollers etc.. Agh! !
But I will try to isolate the cause of that, too...

(... when resizing a slider or progress underneath another scroller 
etc... Agh!)

is it a VID related fix, or View internal one?

Sorry, my previous demo has left older files in your public caches. 
I'll make a "get the latest" script for you....

there is a delete-dir now. shortest way is clean cache.

That could be in a download-script onthat site itself? :)

I am trying to be minimalist here. I don't want to have a download-script 
for every demo I have. That will end up in hundreds of extra scripts. 
I would like to move that functionality into my replacement include 
system, which is still in progress.

simplest way: have a clear-my-site. then all downloads are fresh.

I could do stuff like that, but I am a perfectionist, reluctant to 
admit there might be a simple way that's good enough for now. But 
I'm coming round... :)

Shell-list is designed to be highly flexible and configurable, for 
maximum code re-use. I didn't like the thought of writing a new custom 
list for every program.

I use cache more like, uhm, cache now. like a browser. before leaving 
data is cleared.

advantage, besides simple: I have only the used files in cache. and 
since i can upload too by a filerequester, having only used files 
there helps.

Note to everyone: shell-list is nowhere near finished, but the hook 
system I use to iterate those styles is so significant to me I have 
to make a demo of it.

What I need, to continue with shell-list, is some extra hooks in 
the View system. I need to be able to hook each call to feel/redraw. 
This means a hook in SHOW and probably other places too.

Yes, the demo is not very impressive looking, I admit. There are 
no flashing lights or fancy graphics.

(though I can easily add some interesting variations for each iteration.)

It doesn' t look any different from a window with some normal buttons 
or toggles in it.

But, in a way, that's the point. You, the user of shell-list, should 
not have to care at all what you throw into the iterated-layout. 
It should just work as it would inside a normal layout. That's the 
beauty. The buttons look and interact like normal buttons.

More, what do we do with it now? About using it, building demos, 
maybe 10000 buttons in a row or such things. Where doyou want to 
go with us?

I guess it would be a good base for a spreadsheet?

I guess I am hoping for a bit of attention. I will need some changes 
to the View system or it will not be able to work perfectly. Right 
now seems not a good time with rebcode just released, but this seems 
so fundamental to user interfaces to me I think it's more important. 
Everything always seems to lead back to the list.

I think thare are two slightly different goals. One is to deal with 
the main data in a face. That should be a single value. The other 
is to make a snapshot of a layout, save it, qui script, and reload 
it later. I like that behavior. And i am not sure a single value 
is sufficient for that. But it would be an internal thing about saving, 
as api i prefer something with more defaults, ala VID.

correct me if I'm wrong, but I seem to remember that VIEW can set 
a minimum size a window can have using /options 'RESIZE ?

it seems to respond to 'min-size but won't accept a pair! value...

one would think it's a pretty important feature

didec, thanks. I posted a RAMBO entry about it not being mentioned 
in the console help.

It's a flag in the 'text style that will prevent face/init from doing 
a trim/lines on the face/text.

I can't seem to figure out the solution to do this elegantly: If 
I have a pane with 4 faces [a b c d] and I want 'b to move to position 
'd: [a c d b], is there no easier way than to copy, remove and append 
'b?

Would it be a good idea to open source the Viewtop editor just like 
it happened with the Viewtop? It has a lot of obvious bugs that could 
be fixed by people outside RT.

(or is it a part of the Viewtop?)

Its now in the beta-sdk, dont know how public that is. and you can 
get the source by "probe ctx-edit" from a fresh console. but without 
comments then.

In IOS there is a flag that allows, the users default editor to be 
used instead. It was proposed to implement that in the view desktop 
as well, I'm not sure if it got in there.

So do I, which is why I think it would be nice to get bugs fixed 
and some simple features added like a search/replace and maybe a 
simple undo. I use it alot.

What is the ViewTop editor? Does exists a rebol written editor to 
code rebol programs? Is it in the /SDK package?

I've been thinking about this. But how far would we want to go? Simple 
as in the current editor, intermediate or a fullblown IDE?

Hmm, probably a step by step is the best solution. :-)

I meant write the editor in rebol. Otherwise I thougth to implement 
an Eclispe plugin (Eclipse is a very good platform in my  opinion) 
but why have I to spend time using Java?

I'd much rather see a tad more advanced version of the current viewtop 
editor. No fancy features like syntax highlighting, but useful stuff 
like indenting, search/replace and undo. It shouldn't feel heavier 
than now

I think that every developer need a good developer environment, don't 
they?

question is what is good. scrolling and searching beats a java-style 
treeview with small things.

luca: for me a good developer environment is one that can be started 
with an executable less than 1 MB, and start typing immediately and 
press one hotkey to run the program, and you can learn to use it 
in about 8 minutes.

wizards are a good indication that you are using something that can 
be too complex for the average developer and that gaining full control 
will take you months of learning.

I get a seperate list with the hits and can jump from there. emacs.

volker, well... that's a border line. Its more that wizards that 
can set up a set of files for a compile and you have various profiles 
to work against, but you can't really understand what's going on 
behind the Wizard Curtain. I guess this is OK when you are working 
with C or ObjC programs when you want to build libraries and things 
that are OS specific, but it also tells me that this is hard, by 
default. REBOL should absolutely never go in that direction or encourage 
it.

PARSE could do wonders for a small function browser. I built one 
not long ago.

Also a realtime search bar could be nice. I don't think it would 
be hard to do.

I tried some things based on loaded code. One can search a word in 
all contexts. The other can find the source for loaded functions, 
with a little markup. could be anamonitor jumping to source. But 
never really did that.

That gives the ability to look where a function in some context comes 
really from.

I've also built a multiple file search tool. It's not complete yet 
as it doesn't yet search recursively, or launch the editor on the 
appropriate file, but it's helped me out a few times. I'll see if 
I can upload it...

A good programming approach helps more than a lot of tools. But good 
tools help when you stop on "strange" problems or just need to maintain 
an "old" piece of code or code wrote by others. Do you agree?

the hard part was to walk over to another PC in a different room 
:-)

it would be nice to be able to search something, doubleclick on a 
line and the editor opens and jumps to the right line... also if 
it could be incorporated the same way as we use request-file, request-dir 
and others

Thats what i am thinking. i had a goto-caret with editor working 
once. Only forgot inwhich project.

Gabriel wrote this:
Add a face/refocus function.

   face/refocus: func [shift] [
      ; shift is true if this is shift-tab
      ; do your own refocus handling here
   ]


This  should  be  enough to solve most of your issues. In the past

(View  1.2.8)  there  were  even  more problems, so that I wrote 
a

number  of  patches  and  a Field style that *never* handles focus
automatically. So I could validate and handle focus myself.

http://www.mail-archive.com/[rebolist-:-rebol-:-net]/msg02722.html

Why do I sometimes get several blank lines when I use return? How 
can I just get a return?  I'm using the beta SDK.

Anybody working on a Rebol View version of Sudoku? http://www.dailysudoku.co.uk/sudoku/index.shtml