AltME groups: search

do the timers exist in the win2.7.4 build or only the osx build? 
 couldn't seem to find any relevant ? timer* info..

and to have some fun, it's on us to find what changes as with 2.6.3. 
great...

You can find link to Canvas RPaint under Checklists/Links (the checkmark 
icon up next to the calender here in AltME.

I have very harsh (read as in harsh on rebol) graphics applications 
and it never crashes anymore.  I find it odd that you are still getting 
those!

Then again, it isn't always easy to lift the bug from  [long running 
 / large volumes of data / 1000s of lines of script] applications, 
and set it into a small example.

I once tried to produce a small script that relicated the block-manipulating 
logic of an app I have. I was hoping that running it over night would 
create a "should not happen" bug. It never did.

By way of compensation. I did find this one-liner that will crash 
(without warning) every version of REBOL I've tried it on:

     a: copy [] b: copy [] insert/only a b insert/only b a same? a b
(I think I reported that, but it was before RAMBO)

You will fix the Linux side right?  "Sometimes rebol crashes".  Sorry. 
 :)  I'm still 
attempting to find a short piece of code that trips the segfault.

I started using 2.7.6.

It's great to be able to "call" external apps without the dos window 
popping up. I have alot of use for this. 

I noticed, however, that when calling wmplayer in windows the file 
will play in the background which I also find appealing but there 
are times I might want wmplayer to open. Is there a way to force 
this with call?

I think you'll find it here http://www.rebol.org/view-script.r?script=xml-parse.r&sid=ij461ww

it is probably better to not hide the button, but to disable it. 
You can find enable/disable script on rebol.org ....

post your current version so we might find a little typo...

now I see that in host-graphics.c is used something like:
u32 w = RL_FIND_WORD(graphics_ext_words,RXA_WORD(frm, 1));

            switch(w)
            {
                case W_GRAPHICS_SCREEN_SIZE:
                    x = GetSystemMetrics(SM_CXSCREEN);
                    y = GetSystemMetrics(SM_CYSCREEN);
                    break;

                case W_GRAPHICS_TITLE_SIZE:
                    x = 0;
                    y = GetSystemMetrics(SM_CYCAPTION);
                    break;
...

I never got RL_FIND_WORD to work, but I stopped trying around A102 
I guess and forgotten about it since then.

Here's how I explained to myself how things went:


With A102, the time I started playing around with extensions, there 
was this RL_FIND_WORD which is supposed to map words against an "extension 
local" word block. But sadly, I never got that working.

It was the "temp hack" comment from which I concluded that the preferred 
method then became RL_MAP_WORD, which maps a word to a global word 
id, hence the 1381 number you've got yesterday. With that, you don't 
need to ENUM in your code but can just compare words supplied with 
words known.


But, I may be totally off track with that reasoning ... wouldn't 
take me any wonder :-)

Also, look at system/options/file-types. You can find the file extensions 
that are loaded as R3 extensions, and then go through them, adding 
them to your file's base name to find your file. Or you can add a 
one or two line platform-specific wrapper for your module code.

There are many platforms that use the same file extensions, so you'll 
have to find a way to put the BSD .so files in another directory 
from the Linux .so files. The .rx extension just adds Windows and 
OSX to that.

Oldes, R3 has decided to let the OS find an extension as a native 
library. I really don't want to override that and write my own loader 
in every script

My whole point is: you want those paths _preferred_, but ultimately, 
if you don't find an extension in those paths, you should just fall 
back to the OS loader's search path mechanism.

>> find/reverse/tail find system/options/file-types 'extension word!
== [%.rx %.dll extension]

I will have to look at it. I assume it's not the case at the moment.


Anyone know how to find out the thread ID (not process ID) on Windows?

where can I find the style browser for that gui?

xavier - see my previous message and Rebolek's explanation. My take 
is,that it sould be adapted to release, or ppl will find GUI highly 
non-working ...

A show face user poll:


We decided to introduce a face attribute allowing to implement the 
following show states of a child face of a panel (or, eventually, 
other container):


1) the face is visible and it resizes/repositions together with its 
parent panel

2) the face is invisible, but it resizes/repositions together with 
its parent panel, reserving the appropriate amount of empty space 
for itself

3) the face is invisible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

4) the face is visible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

Possible implementations:

===A


Define a new SHOW? facet (you may indicate your preference to use 
a different attribute name, if you like), which could be set to one 
of the following four REBOL words, corresponding to the above defined 
face show states:

A.1) VISIBLE
B.2) HIDDEN
C.3) IGNORED
D.4) FIXED


(you may indicate your preference to use different words, if you 
like)

---Advantages


*The user can to determine the show state of the face by examining 
just one attribute, the SHOW? attribute.

*When using an appropriate function, the user will be able to change 
the show state of a face by evaluating a

    SHOW-FACE state

expression.

---Disadvantages


*Data are not normalized, seen from a data-related point of view 
- if a user sets the FACE/GOB/SIZE value inappropriately (e.g. if 
FACE/GOB/SIZE is 0x0, while the SHOW? attribute is set to FIXED, 
or, if the FACE/GOB/SIZE is non 0x0, while the SHOW? attribute is 
set to HIDDEN), the state he obtains will not be consistent.

*Speed - since it is necessary to test which of the four variants 
has been chosen, we need to use four tests in resizing code, i.e. 
the code becomes slower.

*More complicated code - it is necessary to take care the state is 
consistent, which may require more complicated code, maintaining 
state consistency.

*Documentation - the users need to be aware, that not all changes 
produce consistent state.

===B


Since the invisibility of faces is already implemented by setting 
the FACE/GOB/SIZE value to 0x0, we need to implement only an attribute 
telling, whether the face resizes/repositions with its parent. A 
RESIZES? attribute (you may indicate your preference to use a different 
name of this attribute) is used for the purpose in this variant, 
possible values will be TRUE and FALSE.

---Advantages


*Normalized data - all four possible state combinations are meaningful, 
and consistent.

*Speed - when needing to test whether the face needs resizing, only 
the RESIZES? attribute needs to be checked.
*Code simplicity

*Documentation - the user does not need to memorize the possible 
inconsistencies

---Disadvantages


*The user does not have the SHOW-FACE function, but, if required, 
it can be implemented easily, it can even use the keywords mentioned 
in the A variant, just translate the state to respect the B implementation.

*The user will not find the keywords in the face data, but it does 
not look like a disadvantage one should be afraid of.


So, please, indicate your preferences for the show state implementation. 
As far as I am concerned, I am strongly in favour of B, so the initial 
score of the show face poll is:

A:B = 0:1

And, as another poll question: do you find all four alternatives 
useful, or would you prefer to use just some of them?

I'm not saying is should be same as above. I'm just trying to find 
out the layout dialect based initialization for all the 'modes' so 
it is easy to use for people. I understand the SHOW-FACE function 
is not a problem to use in both variants once the layout is already 
'running'. I worry about the init part though...

Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)

I hope, this will help you:

faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob/data/gob gob]

The term "faceless" is pretty accurate. What I'm worried about is 
that it will fail if the gob doesn't have any face assigned to its 
data field. It would be more robust to do this instead:
faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob select gob/data 'gob]

iew [hgroup 2 [button 
1" button "2" button "3"]]" - where did you find that?

Pekr: Nevertheless, if you compare the doc Carl wrote with the new 
source that will be published today, you will find out, that the 
difference is not exactly huge.

I think that every novice, when trying to change e.g. button color/border, 
find himself in a situation, when he influenced all buttons, etc. 
It was because direct path modification vs using make for subobjects. 
That is why I welcomed the move to declarative style definition, 
where the distinction could be made ...

OK, I will try new version, and see how it goes. I would welcome 
an example on 'intern, maybe I will find it in sources. Starting 
to warm-up to new gui :-)

I can see you use empty rows to separate some items in facets block. 
Why is that? I did not find any example of 'internt being used, so 
I think that might be the reason? To simply separate/group some items? 
Aren't we wasting memory here?

OK, I'll continue tomorrow ... I can see content fields - dunno so 
far if it is kind of equivalent to R2's pane, or what ... need to 
find content handling functions ....

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

 - not a big deal, really. My problem is, that what I want is behaviour 
 of panel style, but without gfx borders. But - I could create new 
 style, removing the visual elements of panel. Maybe such a style 
 could be added by default, but not sure others would find it usefull, 
 nor do I know what name to use ...

Maybe such a style could be added by default, but not sure others 
would find it usefull, nor do I know what name to use ...

 - yes, that is possible. The difference between original, Carl's 
 implementation, and the new one is, that you have all the box model 
 attributes accessible, so you can do it easily now on your own.

I find other names better, like content or collection.

afaik, its within the port mechanism, when events are created, for 
some reason, the resize events don't end up at the port handler.


I remember trying to fix this in the host-kit and didn't find the 
solution.  I tried a few things but nothing worked... so I moved 
on but that's like 3 months ago already so the details are fuzzy 
in my mind.

set-panel-content is imo definitely buggy (well, apart from the fact, 
that when I find the bug, most of the time the bug is elsewhere :-)

Or I have something wrong in the demo code, not yet fully adapted:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [

  pan: make-face 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right
]

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	bar
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold
			]

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
current-panel
					][
						request "Note:" "Pick a test first."
					]
				]
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
			]
		]
	]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]

So - I should forget Doc, right? Because I wanted to find the reason 
for it to doubling the content, so I wanted to fix it. If it is going 
to be removed, that would be waste of time ...

I am still busy on my business trip, returning home tomorrow. I am 
thinking about producing Wiki article about what I find non optimal, 
or what I don't understand. So far I have gripes with 'options block, 
which does not map directly to facets, but is - artificial. That 
part has to move to declarative style definition, as it influences 
how you use the dialect ....

Panel resizing user poll:

Background information:


For resizing purposes, every graphic element (including panels) has:

INIT-SIZE, MIN-SIZE and MAX-SIZE dimensions:


* INIT-SIZE is the size that is being resized (magnified or minified),

* MIN-SIZE is the smallest possible size of the element after resize,

* MAX-SIZE is the largest possible size of the element after resize.


Until now, we used auto-sized panels, for which we always (after 
every content change, like insertion of a button, etc.) recomputed 
their INIT-SIZE, MIN-SIZE and MAX-SIZE based on the sizes of the 
elements the panel contained.


Currently it looks, that there are many reasons, why it may be better 
to *not automatically recompute* INIT-SIZE, MIN-SIZE and MAX-SIZE 
after at least some of the possible change types.


Therefore, we introduced a non-auto-sized panel, which auto-computes 
INIT-SIZE, MIN-SIZE and MAX-SIZE on-demand only.

Our questions:


* After inserting a button (or other contents), what do you think 
should be the default action - recompute all the above values, or 
not recompute any of the above values?

* How to specify a non-default behaviour? Cyphre came with a proposal 
to use a /UPDATE refinement accepting a WHAT block, so, e.g. /UPDATE 
[MIN-SIZE MAX-SIZE] is required to update just the specified dimensions. 
Would you find a different alternative more convenient?

current behaviour allows inlined set of init-set, which has no effect 
though, and hence causes user confusion 

 - that is not true again, since the user can examine the INIT-SIZE 
 attribute, he can easily find out, that it has been set as specified. 
 What was not set (and not specified) is just the MIN-SIZE and MAX-SIZE 
 values.

If I would not meet with Ladislav, I would not be able to find out, 
how are those things related. That is time-waster to anyone trying 
to study the system ...

My idea is to have style "simulator", having just few named code 
areas, representing above post style: [ ......] structure. Then by 
protytyping, you would be able to develop full style, by putting 
code into particular slots. Well, that could be done even now, but 
I don't find a reason, why e.g. draw blocks, or actors are there, 
but code like options block handling, supporting functions, materials, 
are not part of the process ...

yes, you shall find out, in general, "floating" means - the resizing 
algorithm influences neither the size nor the position in any way, 
i.e. the element "floats unnoticed by the resizing algorithm"

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

And now also - back to point 5, away from politics :-)


- New resizing model. Will API change too? Or is is just internal 
change, so I don't need to care about it, apart from knowing, that 
in some cases, resizing model will be more efficient?


- Is RMA building any commercial app using R3 GUI right now? Because 
I still might miss something, but style-wise I find it difficult 
to imagine, how it could be used. (Tables, lists, tree, area, tabs 
missing or buggy?)

And where can I find an up to date version ?

We shall find a way, how to put in a more informative value.

Some of those color combinations I find hard to read ..like the white 
text on a gray/white button background

That would be bad, Graham. We want that error triggered, or else 
it would be more difficult to find.

a little problem (perhaps only with wine) it is the resize of the 
application with the left bottom corner. the app seem to not find 
a good size !!!! flashing !!!

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

By creating new contexts, we would have to have an advantage to using 
them. In a way, I don't mind it, as it could be used to apply particular 
groups of facets, in a standardized way, so you know that a particular 
context will have these items. But FACETS does technically not prevent 
this. From a technical perspective, I'm not sure I can find an advantage, 
since there is no difference from R3's perspective on speed or efficiency 
in accessing size, color or hinting information.

However, I can see the following groupings or contexts:

- color
- hint
- size

as for your examples - this is method I used before. I thought that 
you might find a way of how to do it in terms of just one panel, 
which is not imo possible?

Guys - to make it obvious - I can find out the way of how to make 
things work. I was just curious, if mine example could be done in 
some easy way. I hope you don't take it as a complaint.

re "I thought that you might find a way of how to do it in terms 
of just one panel" - it is possible to do it in "just one group". 
Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts 
than R3-GUI (H/V)panels.

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

Yes, unification is necessary, correct, we just need to find which 
alternative is preferred.

I wrote it above, did you find the post?

is it possible to find a different word?

I was going to suggest a couple of alternatives but it is hard to 
find something that fits in with the VIEW/VID/GUI metaphors.

yes, merged, sorry. Simply put that when Carl reappears, and starts 
eventually to proceed with RT's releases, to not find ourselve in 
a situation, when Carl uses old and different hostkit View sources 
...

User poll questions:


1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?

2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?

You might not have noticed, but the reason why I am using polls is 
to make something that you would find preferable to other altermatives. 
If you don't know what you prefer, then, you are free to not answer.

I find that if something should be decided, you should look at how 
easy it is to change the code based on that decision. The easier 
the code is to change, the later you can make the decision. This 
gives people a chance to test the GUI with that particular decision. 
In this case, we are working purely with style names, as far as I 
can see, which is possible to change in a few seconds, if we don't 
like them.

I think that ppl will find their way around it ...

1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.

What you are basically doing is some OOP aproach here. But adding 
the code to the end? Who decided that? There are three levels - replace 
action, pre-init, post-init. So what do we choose? In Visual Objects 
I had all three capabilities. Dunno if you would find that usefull 
though ....

no, just real-life aproach. If there is a risk, that half year SW 
might be outdated API-wise, I would at least check how safe I am 
using last published distro,no? But - everything is solvable - those 
who really want, surely would find their way to the latest stuff 
...

GrahamC, I think the issue here is that the bug can't be found unless 
Carl provides a debugging version of R3, so we can find where the 
bug occurs, whether it's in the host kit or the core. I can't be 
sure as it's something that was discussed last over 6 months ago.

About examples: if you download the repository, or the source archive, 
you'll find a test directory which has the test suite for (almost) 
all the modules. the tests are often usable as "examples" for how 
to use the modules themselves.

My approach was, instead of doing what many others do (try to remove 
things from the HTML that are known to be "bad", eg. use regexps 
to remove anything that starts with "javascript:" or anything between 
<script>...</script> etc.), was to only pass what was known to be 
good, and ignore everything else. This is a bit more limiting but 
I consider it to be safer (you don't have to play a game with attacker 
where every time they find a new vector, you have to add it to the 
"bad" list).

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.

I added 2 more cases to the paste (2 annotaitons). load-html seems 
quite complex since it uses many other modules (that I don't understant 
either).. so I rather see if you find something obvious in my approach 
or the bug in power-mezz

Indeed.. I tried to find them myself but didn't think to look in 
changes.html

Cyphre - I am not sure if we should accept CSS document model here, 
as users/designers are used to it? I tried to search for some typography 
vocabulary, but there is not much in it:

http://www.proximasoftware.com/fontexpert/terms/


Then I also looked into MS Word (well, not the best DTP option, I 
know :-), but I am somehow satisfied, how paragraph styling is done 
in it, and I find it pretty much flexible. So few of my notes:

PAGE:
--------
- text-gob - let's say it equals to page


- margin should allow to set 4 sides, as is with CSS and even DTP 
systems. DTP system talk about margin as about the space to the edge 
of the paper. I don't know, how such terms are used in conjunction 
to R3 GUI, but we should somehow find-out, how to not be confusing. 
But - having just a single marign is not imo sufficient.


- origin should replace scroll, and it should mean offset. But looking 
into VID2, origin just did what you propose - but I don't like it, 
as it required us to introduce offset to VID2.

PARA:


- indent - e.g. MS Word defines: indent-left, indent-right (kind 
of creates margins/padding, if you relate to CSS terms), then they 
have indent-special - first-line | "pre-indent" (-first-line,not 
much usefull). It also has check-box for "mirror setting", which 
changes indent-left to inner, and indent-right to outer (dunno what 
it is good for)


- spacing - top-space | bottom-space - but here, it is not inner 
space in paragraph, it is more of an indentation between paragraphs. 
In other words - I can imagine calling it even padding (as we are 
used from VID2, we used space there for the auto-spacing). It allows 
you to set, that it will not add space in between two paragraphs 
of the same style. It also allows you to set spacing for rows - either 
by float, or by multiples, 1,5 rows, double, the-least-possible (pixels), 
exactly (pixels)


- paging - some stuff to set in regards to paragraph and paging, 
as linking of paragraphs, linking of lines

- runaround settings (dunno if correct english term)

trying a disk restore app to find it in the deleted files on disk.

that is true.. I couldn't find a 109 version

Andreas, can I diff against 107 to find out which vectors I'm missing 
and where to put them?

then give a note to carl so that it gets changed in the next host-kit. 
  cause I don't find it a good practice anyways.  strangely, I was 
wondering if BOOL would cause compiler hickups a few weeks ago.

we can probably find some way to handle BOOL via the reb-config.h

Easiest way to find all the posted results:
    http://www.rebol.org/aga-search.r?q=disk/file

this is old Carl's gui. I am not sure it works, most probably it 
does not. Go into R3 GUI group here, and find some of Henrik's links 
and download RM Assets' GUI

5) The amiga being such a different beast, its a good way to find 
any problems and make it a better API overall for all platforms.

Carl's disappearance also made me forget about those changes. But 
as he writes in his most recent R3 blog post "If I can find any other 
changes this weekend, I will merge them.", maybe they still are of 
any use.

Otherwise we'll see after the A111 release :)

Hmm,  I respect that you find it useful, but what if other users 
(like me) find it unuseful?

In the case of LENGTH? and INDEX?, we are only allowing them to return 
none when passed none, using none as the equivalent of SQL's unknown, 
not N/A. And even those are a bit iffy - we are only planing to allow 
those to have fewer intermediate none checks when doing none pass-through 
on FIND and SELECT return values. However, the disadvantage is that 
errors aren't triggered close enough to the source of the error. 
Hopefully they will be triggered later by ASSERT calls.

That is a seperate issue that needs its own ticket. FIND and SELECT 
use their own code, so they can only follow the same rules, not use 
the same code.

It's not decimal precision which makes the FIND (and STRICT-MAP!) 
discussion so cumbersome.

Strangely enough, it's not binding or exact decimal comparison that 
are at issue with FIND or strict-map! either, it's case and type. 
Nonetheless, this would make it easier to point to the distinction 
between STRICT-EQUAL? and STRICT-EQUIV? when talking about those, 
precisely because those aren't at issue.

So that would make it easy to define FIND as using EQUAL? per default, 
and STRICT-EQUAL? with /case.

this implementation is order safe, removing the duplicates from the 
end rather than those in the begining

remove-duplicates: func [
	series
	/local dup item
][
	until [
		item: first series
		if dup: find next series item [remove dup]
		tail? series: next series
	]
	series
]

I always wondered why it reduced... I find that very annoying... 
many times I'd use it and It ends up mucking up my data, so I just 
almost never use it.

To find out what is wrong, just write an "in place" version of Deduplicate 
in Rebol, divide the time needed to deduplicate a 300 element series 
by 30, and compare to the algorithm (in Rebol again) allowed to use 
auxiliary data.

You shall find out, that the fact, that the algorithm is native, 
does not help.

You shall find out, that the difference made by an inappropriate 
algorithm is so huge, that even as a native it would be too slow 
compared to an efficient algorithm written in Rebol

A couple projects that I would find interesting:

Went through the Parse Proposals list and tweaked the Priorities 
section to double as a status list. Unfortunately, some of the rejected 
proposals must have at some point been removed from the proposals 
page. We wanted to document them and why they were rejected, so they 
don't get proposed again. I may have to go the history and find the 
rejected proposals that were deleted and restore them to the page, 
so they can be rejected explicitly with explanations.