AltME groups: search

about list, thats a complicated issue IMHO, because list is heavily 
optimized to show very big lists with good performance and low memory 
use. Thats done by a trick (iterated faces). And that trick is hard 
to wrap in a generic way. 

The other option is to do it trickless, means put all in a big layout, 
one face for each row. thats like conference/messenger/altme do it. 
not that performant (all this programs restrict the number of messages, 
only the last n). but to do it, you only have to append vid-code 
like
 text (name) 100 text  (msg) 300 text (date) 100

for each line and layout that. most flexible way, you can even edit 
each field. but don't come back and tell me its hungry/slow! then 
you have to use that index count list - stuff, maybe somewhat better 
wrapped.

Volker: but Cyphre, with his my-list, can display millions of records, 
as it uses caching, yet it does not suffer from 'supply problem I 
outlined. And btw - interesting point towards 'list. I wonder what 
was the reason Carl did not put his improved list into 1.3? It was 
created in older 1.3 project days, along with chech-line, radion-line, 
which are inside, newer list is not. It seemed to me as tested, improved, 
 compatible, so worth inclusion at least ...

Allen - I talk about precise plan for 1.4 - so really - genear info 
of "Yes, 1.4 will come after 1.3" somehow does not help here :-) 
I talk about details, simply kind of resurrection of older 1.3 project 
days, where we held talks about VID, each style etc. And it can get 
pretty tricky. You remember? We had problems to agree upon new button 
:-) The worst thing is - we have to keep backwards compatibility 
in mind :-(, so projects like RebGUI have some advantage here, starting 
from scratch. I e.g. wanted area having automatic scrolliers, but 
Carl did not agree because of compatibility ....

Volker - thanks for 'dirty explanation. It seems to be handy. But 
- does 'dirty work for other elements too, as e.g. check-box? In 
old x-base days, we used to use scatter and gather methods. So, if 
'dirty flag solves just fields, it shows incompetence of designer 
imo ;-), such thing should be done via accessor functions - set-face, 
get-face, which eventually can even format output, e.g. in the case 
of radio button to translate into some other value. Robert with Cyphre 
e.g. defined "form dialect" for Robert's private IOS effort. Did 
not see it in action, but probably it tried to solve things in more 
general way.

So - stating that - I would really appreciate such things to be documented 
or at least discussed. If we start to add such things into VID, it 
should be agreed upon by more wider audience. I e.g. have rather 
good experience with x-base databases, others surely too, but if 
the solution works for 80% of cases only, it will once again lead 
programmers to simply ommit what is available and introduce own, 
more complex scenarios ....

Few additional notes, to not understand me wrong. I always try to 
see the bigger picture of things, not just from the pov of current 
View user. IMO VID should develop towards general "solution containers" 
= highering common ground for further developments. So - the solution 
is not to introduce one quick hack for particular style, but generalising 
things and letting ppl to develop their own solution, but using that 
common denominator. Good example is Rebol, its network protocol, 
and Uniserve - Uniserve is good example of taking things further, 
so each user does not need to start from scratch. In VID it is e.g. 
introduction of accessor functions. I suggest to try to find other 
"solution containers" :-)


The other thing ppl should think openly about, is to sacrifice backwards 
compatibility! I do remember ppl here screaming even about single 
change, which would eventually broke their code. Man, it sound like 
some of us woul never been with bigger projects? Our SAP workflow 
engine is some 50K lines, and when I asked my co-worker to add another 
functionality, he said - I will hack-it in, but I will REWRITE whole 
engine to be more flexible. So - that's me and ppl I work with - 
let's be sane - as I stated on ML - View starts from 1.3 ;-) But 
even further - let's not be selfish to the thousands of ppl, which 
may come to Rebol in future. I don't want to explain to anyone, that 
thing x or y is there because there was some compatibility issue 
with Rebol 0000.1 alpha and som eppl got tens of scripts already 
- that is imo selfishness in bigger picture, sorry to say that. Use 
old kernels for old apps. Our code will break anyway here or there. 
I prefer PURITY of solution instead of compromisses. So that is my 
message to future developments :-)

Pekr: It is a good time to start looking at the next VID, and see 
what else from the VID project can be used. You are in the best position 
to identify which of those pieces are finished or worth pursuing.

such thing should be done via accessor functions - set-face, get-face

 - i think Carl changed philosophie here. The old vid is good for 
 simple forms. Why use an accessor when you simply can inline the 
 data into the layout? But it works not so well when you want to change 
 displayed data. Text-list for example where not even prepared to 
 have data updated. thats where accessors come in. instead of re-layout 
 reuse the old faces and change their values.

About happily breaking code, IMHO thats for major versions, 3.0. 
and then not only some somewhat improved styles, thats not enough 
to break compatibility. Then Carl should have the chance to invent 
some things new.

Gabriele - I am not sure, with Terry, it was imo old View vs Flash, 
then came-in devcon and first introduction of AGG, which was happily 
applauded, but it does not really matter ...

(ah, forgot to reset color, sorry ) ... Anton - you can ask me to 
slow down, but in such case I usually "give up", instead of "slow 
down". Some design issues are really important at certain points, 
and if I e.g. ask for some "what's next for new VID from developer's 
pov", I can't be referenced to doc, which says basically nothing 
about it ....

Volker: using different methods to set style values is basically 
a wrong aproach imo, e.g. methods for automatic iteration and data 
collection are more difficult to do, as you have to inspect what 
style are you investigating, and what is the method to get the data.

Petr: i remeber that discussion very well, i was the one to say that 
View was going to be better soon, and i said that because i was testing 
AGG View already.

and i wish to stress this is just IMHO

we need something like VID2, created from scratch (or almost), and 
strong enough to serve as a building base for applications.

i think that there are lots of subtle design issues that would be 
too hard to solve if we wanted to keep compatibility and just extend 
VID.

rather, i'd keep VID as is for compatibility and provide a brand 
new VID2.

And what is more, - there are other planned changes to View kernel 
- fonts in AGG  (under considertion IIRC), text mark-up, 'min-face, 
which will maybe in itself influence even current VID and the way 
we use it, if such concepts are implemented ...

There are several of you - gurus, who could outline in few paragraphs, 
what way should VID2 (or VID+) go

Actually, I think it would be easier to design and implement it than 
try to outline it in a few paragraphs. :-)

problem 1) is: i don't know what VID2 is. we need to decide the goals, 
design it and so on.

problem 2) is: this whole issue needs discussion. we need to discuss 
it with the community and the team; then Carl has the final answer. 
so, if community prefers some changes to VID rather than VID2... 
no point in wasting time with VID2. and so on.

Volker: re practical usage of dirty flag - you said, that when dirty 
flag is used, field value is always saved? I tried following example, 
and it is saved too. What am I doing wrong? Following code, even 
if dirty is set to 'no, still saves the value, even if I click outside 
the field ...


name: "petr" view layout [f: field name [name: f/text] field "test" 
do [f/dirty?: no]]

dirty? is set when the text is changed. try this:

 name: "petr" view layout [f: field name [print "1" name: f/text] 
 field "test" do [f/dirty?: no]]

then click inside and outside and edit etc. the action is triggered 
when you change it and click outside.

accessors - i did not mean different methods as in "methods fr different 
faces". its different concepts. in old vid it works this way:

you put data in the face as in [filed "Hello" check on] etc. kind 
of set-accessor.

when data changes, you handle it in the action and pt it back in 
the db.

the action gets a parameter 'value, so instead of of field/text, 
check/data, text-list/picked/1 you can just use value. kind of get-accessor
  field record/name [ record/name: value ]
  field record/address [ record/address: value ]
  check record/iwantit [ record/iwantit: value ]
  button "send" [ send [me-:-here] mold record ]

and when "send" is clicked, all that values are already in 'record

and for a bit performance the field-action is not called on every 
key, but in the last moment. also more usefull if you want to convert 
it first to a number or such.

then people started to be more performant and "living", changing 
the face-fields instead of relayouting. resulted in all that dealing 
with /text /data /internals. and then Carl unifiied that with accessors, 
so that we deal with set-face, get-face, and for storing we have 
set-face/get-face for panels.

saving later - yes, the face keeps its value. you can as well get 
the value out of the face. only the action may be called sometimes 
in between and suddenly do something. in my example its just a store 
and each action overwrites the old value. if you change layout there 
or such it may led to surprises.

.

vid2: Has somebody ever tried oberon/blackbox-builder? Thats the 
kind of layouting i like. They use text with "active-x-controls" 
inside (only better and simpler ;) . blackbox can do really windows-style 
guis that way. then while developing you can mark part of that gui 
and just copypaste it somewhere else. gives a lot easier control 
than typical gui-builders IMHO.

I noticed a change in image! type offsets in view 1.3 compared to 
e.g. the rwdraw57e.exe version. In rwdraw57e offset 1x0 was in the 
corner, now it's offset 0x0. Example:

>> bitmap: make image! 100x100
>> change/dup at bitmap 1x0 red 8x8
>> view layout [image bitmap]


That piece of code would put a red square in the corner of the bitmap 
in the rwdraw57e version of View. In View 1.3, the second line should 
be:

>> change/dup at bitmap 0x0 red 8x8


and I think, it's a good change. You could argue, that the offset 
should be 1x1 in the corner, like series are indexed from 1, and 
not zero. What do you think?

What you see is the hex from the change and forward. To see the bitmap 
from the beginning, just type bitmap at the prompt.

I have posted this once while in the first REBOL world and up to 
now things are the same. The trouble is while I am posting this I 
notice the foreign characters under Linux are yet not supported by 
/View. I am using Debian Ubuntu with brazilian ABNT2 keyboard layout 
and I am not able to input some characters used in Portuguese such 
as ´a ´e ´i ´o `u `a ^o ~a .

This is a View application .. and I see them

that´´s not what I mean. they are visible but the accents are misplaced. 
for instance in the word coraç~ao (heart in English) I should get 
the tild uppon the letter "a" and not before it. got it?

we need Unicode. It is already one year ago or more, when Carl told 
me, that RT received more requests for Unicode support and that it 
is relatively high on their to-do list. But who knows what does "high" 
mean here :-)

Carl knows the problem ... well at least I had the chance to talk 
to him once trhu a feed back... and also there was a ticket in the 
past ... i remember... but then

I was working on my knob style and I realized that the knobs look 
like flying saucers from ed wood films. so here is simple demo - 
do http://krutek.info/rebol/ufo.r

Allen had mentioned using rate to handle forever loops in action 
blocks but my problem is that i have a while loop that executes a 
lengthy amount of functions before it even loops again.  I almost 
believe I need a multi-threading way of doing this.   I thought about 
it for awhile and think an enhancement would be nice where you can 
for example use launch function for executing additional threads 
but have a memory space for passing data between the threads.  Any 
of the REBOL gurus involved with RT know if something like this is 
capable?

dunno, probably not a bug, but at least a cache headache - imagine 
following scenario. Today I did small script for my friend. I created 
C:\app-name-here directory and put it inside, along with rebol/view. 
I then decided to install View, to get .r association, so that my 
small scripts could be put directly onto Window desktop (I don't 
need yet another desktop - View one, If I can't parametrise it further 
- buttons, removal of rebol.com etc.). So, after installation, I 
filled in network info, saved, and exited view. Then I could see, 
dirs like 'public, 'local 'desktop were created.  So I deleted them, 
to remove additional clutter they caused in my directory. To my surprise, 
View ignores the fact it is already installed, I choosed to not use 
desktop, yet I was brought to desktop once again.

oops I started looking for more and toggle and forgot to say the 
problem  XD


Pop is just supposed to.. well.. pop the buttons up, but it won't...

Hi Gabriele, Is there a possibility of putting aliases put in place 
so View has that consistency across all the styles?  I think we also 
have /value and for a text face /text when I think it could always 
be /data

set-face and get-face are the answer to this problem. accessors still 
need to be written for some styles though.

ah, also, you're comparing text-list and scroller. mmm.

and, this explains why noone noticed it so far.

Geomol, I think the problem is because the dragger is only correctly 
positioned in feel/redraw. See the feel:
	layout [slider with [?? feel]]

This means that the dragger is only set in the correct position when 
there is a redraw event, and the face must be viewed in order to 
receive events. The initial position ( layout [slider with [?? init]] 
) does not take into account that DATA may be non-zero.

OK, submitted this bug and fix to RAMBO.

Do this and you will see why your first test didn't work:

Anton, I was producing the quick list of VID-styles found on my homepage 
and needed some images to go with it. I saw the bug, when I was making 
the image to show slider functionality.

that's because you must drag mouse up/down and not in circle

I am not sure it should work by dragging the mouse up and down ... 
you should be able to hold the knob and do circular movement imo 
...

In Reason and FruityLoops (audio sequencing software), up/down is 
the default behaviour.

METAR/ TAF information are comming from airports weather system and 
are usefull in aeronautic

My point is O I make 8 images and show the  right one according to 
the datas

or I make one image and I make a dynamic arrow using draw effects

in all cases your code is a good example  and a usefull working pass 
for me

Actually in the fairebo's dashboard  I only symbolise weather and 
temperature and for complete weather description we have to report 
to the text report (witch translate the METAR/TAF informations)

What I want to symbolise is the wind speed and direction and the 
humidity

My idea was to make a images that symbolise the cardinal direction 
(rose of the wind) and using draw effect over draw information like 
arrow or text :)

Kru, yep, definitely like your style Kru. Just skimming your codes, 
nice and clean. Your multiple colours handling looks smart, too. 
Something I haven't implemented so fully and nicely.

Kru and Anton. Both excellent demos! Should we add a folder on Viewtop 
for custom styles?

drag the stick at what ever position stay with the mouse button down 
and you will see the pair position text to be increment every seconds

mad but beauty full and original way to symbolise things like meters 
etc

some configuration range too instead of having a silder and a progress 
bar

shadwolf why not, what's the difference between VID and REBGui widget?

It's not a bug but an intented behavior : it's a pair input style. 
There is for steps, each step can add any value to the pair. The 
repeat speed is also a parameter.
ie:

 stick-style speed 8 steps [1 2 5 10] ==> 8 is the repeat speed (rate) 
 and 1, 2, 5 and 10 are the values added to the pair!, depending how 
 you move the stick.


 stick-style value-mode decimal! ==> value is a block of 2 decimal! 
 values rather than a pair!

And feel/redraw is a nice place to detect changes to the face, eg. 
when face/data changes, you can update the visual state of the face.

Does anyone else think that might be useful, and should I post a 
rambo ticket to request that ?

Ok, I don't need the new action anymore; I simply avoid recursion 
possibly caused by the face/action by setting flag. Here is a demo 
showing face action trying to recurse, and redraw catching this using 
the flag:

It's good (took me hours to arrive at this simple solution :)  Now 
the action block can do whatever it likes, including showing the 
face, and redraw can handle it.

Is it possible to make View evaluate an expression and send the output 
to STDOUT under Windows? I'm not having any luck with my attempts:

	C:\Program Files\rebol\view\rebol.exe --do "print probe system"


This just opens the View Desktop, and doesn't seem to eval the statement.

hmm ... that doesn't do it either. I decided to get Core and use 
that for my purposes.

I found that my previous redraw action handling example is not quite 
perfect; when the effect block contains [merge luma 20] and the action 
block contains a show, and when the window is shown again after being 
covered by another window, then it appears the luma is applied twice 
(ie. twice as bright).
Anyone who copied the above example should add that as a note.

Hi all,


if I want to know if there's any dirty face in a "window" is there 
a faster way than looping through all faces in the pane, and check 
wether they are dirty?

What I want to do is to add to AD for each day of a month (31) single 
panes, that have the number of the day as text and mark weekends 
in red. The numbers should appear top-down for numbers > 10. so like 
this:
1
0

Is there any difference between TO-STRING and FORM?

form and mold go together, conceptually. FORM is like "convert to 
human readable form", while mold is like "convert to rebol readable 
form".

The best I can think of is looping through face/parent-face/pane, 
checking offsets, and activating the correct one... I'm hoping someone 
will have a nicer solution, though  ^.^

You mean make a face "transparent" to events ? You click right through 
the box, and it hits the checkbox. I did something like that once....

It helps to know if the covering face is the same size and offset 
as the face below. (then you don't have to modify the event/offset)

See my newly uploaded package - %Entity.r - I'm looking for ways 
to have some unusual fun with Rebol faces, and right now I'm trying 
to get it to draw one top of everything, but still let buttons and 
such work

and to emulate events better, you can also do this:
 reduce [e/1 e/2 e/3 e/4 e/5 e/6 e/7 e/8   offset e/offset ..]
then poth event/1 and event/offset work

ehh.. 10kb will take a while for me to go through *and* understand 
- for the moment I'm sticking to transparent-events  ^.^  eenyways, 
lunch and work meeting, then I'll start  >.>

and from rebol 'win-offset? to find the offset in your face, to add 
to event/offset . that should give the face under mouse.

Is it currently possible with REBOL to have always-on-top dialog 
box, so I can e.g. urge user to select/enter something and will not 
allow him/her to go back to underneath window screen?

... and I tend to agree with someone (do not remember now) who submitted 
RAMBO bug re strange behavior of 'over function. It is imo useless 
(try to prove me being wrong), if 'engage has to be used instead 
for "over" detection, when e.g. mouse button is pressed ... because, 
imo, it still belongs to 'over, although it is a bit "engaged" :-)

hmm, I copied and run above in my console and it displays message 
"Cannot run ...." to me ...

Levelarc is nice but unfortunately shows some small but noticeable 
inaccuracies in agg (implementation ?). Not a showstopper and hopefully 
they will be fixed in good time.

We should not complain here probably, as this group has web-public 
flag and is web-visible :-) But, you are probably right. Rebol is 
meant being cross-platform. It was said SDK and other platforms will 
come shortly after. We all probably differ in what does "soon" mean. 
E.g. no single last year devcon announced technology change was delivered 
yet, and that is not a good signal.

RT showed very good signal when they choosed few of community members 
to bring us View 1.3. But I thought things will go faster. Some kind 
of Rebol DLL was talked about in the past, which would bring us some 
parts of Rebol open sourced, to be ported faster. Now we wait for 
Linux "recompile" of View 1.3 for so long and noone does know why. 
I would expect blog article covering "What's next" and especially 
WHEN?

Other strange factor I noticed, and correct me if my feelings about 
it are wrong somehow. The same way as Altme "has stolen" some life 
from ml, once there are some business oportunities for top rebollers 
(and I really wish it to all of them), community seems to be kind 
of dying. We can see ppl like Cyphre, Doc being almost invisible 
in the sense of community activity (posts to ml, or even here on 
altme) ...

ALtME always pops to front and I did not notice

Now we wait for Linux 

recompile" of View 1.3 for so long and noone does know why." You 
do. Fonts.

http://matplotlib.sourceforge.net/fonts.html, they say "The GD, Agg, 
and Paint backends all support freetype fonts, which provide high 
quality, anti-aliased font rendering to PNG and JPEG output without 
X support.". Not directly usable for us, its a python plotting lib. 
But maybe something can be learned from the source, or asking them?

http://freetype.sourceforge.net/license.htmlfreetype can be credits-bsd. 
and i guess every distro has an easy way to install it, if it is 
to big.

http://www.freetype.org/freetype2/index.html"can return the outline 
data (and control instructions/hints) to client applications", i 
guess thats what is needed for vector-fonts?

It give same result uner 1.2.48 and 1.3.1

I have a iterated face that draws some text at different x-offset 
postions. Than the user can change some things and text will be drawn 
at other x-offset postions. The problem is, that the text drawn first 
is still there. The face isn't cleared... how can I do this with 
iterated faces?

It's just a simple iterated face-function is described by Carl in 
his blog and view-doc.

~Hides~

(School starts on the 24th, and I'm seriously thinking about dropping 
4th year Spanish)

view problem: showing the parent-face doesn't work because that's 
the whole window. The thing is, if the first draw is done and I than 
click into the box that has the iterated function attached, the text 
is shown.