AltME groups: search

According to your words, it seems that you and Henrik have access 
to the code, right? :-) Have you studied Gabriele's VID too? How 
do those compare?

Actually, make-gobs was implemented to make the UI fast. Gabriele's 
VID had to do a lot of calculations in the Draw blocks, and when 
you combine that with the resize overhead it added up. He added make-gobs 
to precalculate some of those Draw calculations.

Brian, I disagree that my system was slow. Indeed, I don't think 
you can do it much faster unless you make it more low level (ie. 
users need to specify more). Even then, I still think the speed would 
be the same.

Brian... it's not like my vid had to do a lot of calculations. ANY 
VID will have to do a lot of calculations. You can write all that 
manually (my proto2) or have a system that writes the code for you 
(make-gobs). There is no third option (well, you could interpret 
instead of compiling in something like make-gobs, but you won't like 
that).

That is a simpler resize model in that you have to specify all the 
constraints yourself, and it does not do tabular alignments automatically 
for you.

Gab, do you plan or already do continue your VID approach? I think 
we have to do some trade-offs between what VID can do in terms of 
simplicity and features.


I think we should try your approach and Carl's on a realy world app 
to see what fits best. Maybe it's a good idea to have a Simple-VID 
(for smaler tools) and a Fullfledged-VID (for big apps).

the rebol politics is rebol is all you need to do software

REBOL [
	Title: "REBOL 3 GUI - Development Module Loader"
]

files: [
	%x-funcs.r
	%g-defs.r
	%g-debug.r
	%g-funcs.r
	%g-styles.r
	%g-faces.r
	%g-panels.r
	%g-events.r
	%g-text.r
	%g-effects.r

	%s-fonts.r

	%s-panel.r
	%s-button.r
	%s-bars.r
	%s-text.r
	%s-image.r
	%s-lists.r
]

code: collect [foreach file files [keep load file]]

len-kb?: func [s] [round/to divide length? s 1024 .1]

src: mold/flat code
gui-cmp: compress src
gui-size: len-kb? gui-cmp 

print ["GUI Size:" gui-size "KB /" len-kb? src "KB"]

do code

Isn't  there a typo?

    faced: [
        bar-color: teal
        bar-size: 1x1 ; modified by the progress % value
        bar-fill: ; generated from bar-color option
    ]


What is going bar-fill to be set to? It is last element of the block, 
and if you do object from it, it should have some value to be set 
to, no?

State as word? Do you mean in face/state block? What if you want 
e.g. focused state to be drawn by glow effect or some animation should 
be made? Imo having single draw block is not sufficient.

So - how do you add focus, or disabled state to button? By just changing 
gradients? Disabled - maybe, but focused?

My friend Abe challenged me to write a simple recursive fibonacci 
sequence and on the 46th iteration the program quits because rebol 
can't do that calculation. I tried it on Linux rebview and rebol/core 
and on windows vista rebview even without running my script. The 
strangest thing is that rebol can add much larger numbers, but just 
not these. Does that make any sense? try the equation in a rebol 
terminal yourself and see what I'm talking about. Very strange.

Matt, do this:
    (to-decimal 1134903170) + (to-decimal 1836311903)
or this:
    1134903170.0 + 1836311903.0

In the DocBase page for GUI_Panels, Carl wrote


A group has no backdrop or border and arranges horizontally by default.


I feel this is ambiguous; do groups have no backdrop or border ever 
or only by default?


I'd like to edit the wiki to make this more clear but I can't tell 
 from the rest of the page whether a panel can have backdrops and 
borders. Can anybody with access to R3 clarify this?

Peter, I also think that, as Chris suggests, borders are designed 
to be invisible, while panels can be seen.  I don't see any reason 
why a border couldn't be restyled to be visible, though. It will 
be one of the first things I'll want to do - hacking if I have to.

Petr, most of the styles in VID3 use just one draw block. Also when 
using multiple gobs, eg. in a scroller, they have one draw block 
each too, and state is just changing the value of some words. Carl's 
version just limits this to a single draw block, without automatic 
resizing. Which, you're forced to do if you remove the distinction 
between feel and look (you're stuck with whatever gob structure was 
in the original style anyway without that distinction).

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

Henrik - I know it might be easy. Carl does not see it as a problem, 
many of you probably too. But using myriad of read-* is imo anti-rebelious 
and suggests that not enough emphasis was put into design. I hate 
how rebservices are polluting name space, cloning all possible send, 
do, wait, open, etc. functions ... but everybody of us has his/her 
own preferences .... I really don't want to end with 100 of read-* 
functions ...

Every major platform uses parametric UI layout and coloring. Even 
it we want to use the system metrics we need to have a way to apply 
them. That means that we require a skinning-capable design just to 
be able to fit in. Plus, if we do it right it's good marketing.

So far, we are solving panel (page) style elements. What I miss is 
one layer above it, namel split-window. Hopefully it will not be 
problem. When I look e.g. at Outlook, the UI is - one window, background, 
and panels. When you move over the space between the panels, mouse 
pointer changes to that of resize. I wonder how would we do it?

Many ppl suggested to accept e.g. SVN Trac, as RebGUI is using. But 
DevBase otoh gave us another good VID expert - Brian :-) He was also 
doing some fixes, which will be part of Core 2.7. Sometimes it is 
good to use your own tools. That is also why Carl is putting so much 
energy to new VID - trying to do some real stuff using VID.

Pekr, R3 will use real modules. The initial public development releases 
of the GUI will not. The module system (and even spec) are not finished. 
We will be able to resume work on the module system soon, and the 
design of the new GUI's code is being done with a module system in 
mind. It's helping to do the GUI first because it serves as a use 
case and inspiration for low-level semantic fixes like a module system.

simply put, button and even panel rounding, even if rather small, 
does not look good, when you place stuff one to each other. E.g. 
with buttons tied close together. While I like button as is, I don't 
like rounded panel at all. Once again it is my preference. IIRC RebGUI 
has it as a preference and all styles adjust. First thing I do is, 
that I go for strict boxy desing, no rounding ....

If such things are not settable, what chance do I have? To restyle 
all styles it should apply to?

Henrik - I understand very well, why Carl tries to keep the design 
simple. And so far, VID 3.4 looks good, that is apparent. But - when 
something is imo oversimplified and we start to hear - "you can't 
do it easily, or the system would be complex", then we should ask 
ourselves - will user call for such features, or not? Because if 
users will require such features, they will start patching the system, 
which is not prepared to be patched, and it can lead to kludgy solutions 
...

OK, I'll wait for addition of focusin/selection system, as it might 
prove, that single draw block might not be sufficient, because it 
can't handle conditional drawing - to draw something, or not. E.g. 
I would like to have some glow like outline blurred effect for focused 
face. How do I do it with one single draw block?

For focusing and such effects, it makes more sense to separate that 
out into a small gob system layered on top of the GUI. Similarly 
for drag'n'drop, bubble help, etc. It's not hard to do.

Henrik: sounds interesting. While I would rather probably have styles 
living in their autonomy = reacting to various events themselves 
(as is correct aproach in OOP system), I do remember how I did 'disabled/'enabled 
style - inserting face (gob) in front of style, so it was independent. 
So you are right, it can be done different way, but e.g. animation 
of the style will not be possible ...

Graham - the truth is, it is set in stone already. The desing follows 
the logic of one draw block per style, plus minus parametrisation 
via facets and selection of gradients to express materials or something 
like that. That is why my opinion is, that we should not do the mistake, 
of first trying more complex styles, but - we should aim to introduce 
all possible subsystems, as focusing, disabling, accelerator keys, 
keyboard navigation. Those things are not vertical, but horizontal, 
and they can show, that you have difficulcy to express it ... hence 
Henrik's proposal, that such "additional" stuff (which is additional 
only because the design does not count them in), can be layered by 
different aproach ...

Ashley - I am not the one who agrees to everything designed by Guru. 
If you are like that, well then. But - we were promissed, that this 
time, the system is going to be done the right way. I really don't 
understand your position, as you surely do understand, what we are 
talking about here. It is not about rounded buttons and such details! 
"all possible arguments" is just one single thing - OS compatible 
behaviour. And if you suggest we should wait 10 years here - well, 
time to move away from VID then ...

We can later try to influence Carl, to decide what is going to be 
done next. If you notice rebol.com R3 section, according to plan, 
next is the LNS overhaul. Dunno how long would it take. And then 
my suspicion is, that in order to release host sources, guys will 
try to do DevBase client in VID3.4 :-) So who knows when do we get 
back to Core ...

Most of the funct functions set global stuff through paths or accessor 
functions. All set-words refer to local words. If you need something 
else you can still use func (and many functions do).

Pekr, being able to animate styles continues to have nothing to do 
with skinning :)

The SET [a: b:] issue:


In current REBOL a block argument to SET for the word parameter needs 
to be filled with values of the word! type, not any other word types. 
This is in contrast with just passing a single word value, which 
can be of any word type. The result of this is that values in word 
block argument need to be converted to word! before being passed 
as a parameter.


There is no reason that those words need to be of the word! type, 
particularly since the block isn't evaluated. One interesting thing 
about REBOL is that a word! bound to a context will refer to the 
same value as words of the other word types with the same spelling 
otherwise. This means that if you set a lit-word! to a value, you 
can get the same value from the corresponding word! or get-word!.


Now, the current behavior has some bad consequences as well, usage 
issues. Some word block arguments had to be preprocessed. The big 
problem we ran into was when we wanted to use SET inside of functions 
created with the new FUNCT function (temporary name).


FUNCT collects set-words from the code block and nested blocks and 
adds them to the function's locals. This is cool and works a lot 
better than I thought it would, and all action handlers of the new 
GUI are turned into functions with FUNCT. The problem we ran into 
is that when we had to use block SET to set local variables, those 
local variables would leak into an outer scope, wreaking havoc. If 
you are specifying the function spec directly there is an easy workaround 
for that: Just specify the locals that aren't caught with your own 
/local vars. However, you can't specify the function spec of an action 
handler in the dialect, just the code blocks (security/stability). 
This meant that if you wanted locals to be captured, you had to set 
them to none earlier in the function. How soon do you expect that 
to fail?


An easy solution to this would be to specify the words you want local 
as set-word! values in the literal word block argument to the SET. 
Those set-words would then be caught by FUNCT without any overhead. 
No problem, except for that SET doesn't allow it right now.


This is what we are going to fix in the next build: You will be able 
to do SET [a: b:] value.

In some circumstances like with FUNCT above, you will likely *have 
to* do SET [a: b:] value. This is where we get to the implications, 
what it means for us: We are making changes to the core, sometimes 
subtle changes with big implications. These changes are coming as 
a result of the work on the new GUI. Some of them are bug fixes, 
some of them are new functions or other enhancements, some are fixes 
to design flaws in the language expressed in functions we have already. 
They will affect the code you write even if you aren't doing GUI 
code. Every change like this is going to make R3 a cleaner, easier 
and more powerful language than R2, even with the backports. Something 
to look forward to :)

Henrik:

- what do you mean by "overlays" please?

- what do you mean by pop-ups being done in separate windows? Pop 
up dialogs were always separate windows, no? Or are you talking menus 
for e.g. too?

- hopefully Cyphre gets contracted to do some fixes/enhancements. 
Do you think, that once it happens, community could dig most important 
bugs in draw layer, and ask for fixes?

Simple answer: I don't think we are currently talking about finalization 
and the color picker was an example, not a feature.


Longer answer: The new GUI is going to be part of the open source 
portion of R3, and open source projects are never really finished 
until they die. So the question here is not "finalized" but "ready 
for a release to the wider developer community". In order to do that 
we need to put together the core design of the infrastructure and 
enough styles to get the new DevBase GUI up and running. Right now 
we are focussing on styles and features that have the most impact 
on the system as a whole, or the most potential to flush out bugs 
in the underlying runtime.


If it all seems low-level, that is because it is. We will have a 
development release before we have most of the styles you mention 
because we will need the help of the developer community to make 
those styles and more. However, don't expect the styles you list 
to be missing - some of them meet the criteria I lested above, like 
helping flush out design flaws or use in DevBase.

Probably the first, since it's about Cyphre having time to do them.

Henrik, I'll have another look at that video but I do not recall 
what you are refering to.

We can go with layout-to-pdf or layout-to-html translators at first 
run. Well guys, I wonder what you will say, once sources are released? 
Then it will be fully upon us. Printing is imo not a priority - it 
first needs to be studies, then implemented - how to do it in cross-platform 
manner?

Source code for the style:

doc: text-area [


 about: "A tiny document markup method for embedded docs, notes, messages."

	options: [
		text-edit: [string! block!]
	]

	actors: [
		on-make: [
			; See text-area style for details.

   face/state/value: face/facets/text-edit: parse-doc face/facets/text-edit
			init-text-caret face ; (call before make-text)

   append face/gob gob: make-text-gob face face/facets/size - 2 "empty"
			face/gob/size: gob/size ; estimate to start (may get resized)
			do-style face 'on-update none
		]
	]
]

Henrik - looking at your latest screenshots, are those all inkscape 
based? One thing is imo clear, we need gradients for lines, hence 
your request. I would like to ask about so called "default skin" 
- do you have some concrete artistic idea, or do you aproach it by 
trial and error aproach? What I e.g. like about Carl's Autumn skin 
is gradients for backgrounds. So far I like mild blue (Fedora, Vista) 
tones, and I think that the era of "grey" systems is over ...

The reason the octagon and triangle are inkscape based are also because 
scaling a rounded corner is very hard to do unless you to it correctly. 
It even took some time to get right in Inkscape.

When I spoke about addition of some other subsystems, I simply meant, 
that for the release (not the development phase), we can't afford 
to do the same mistake as with VID2 ... but so far, even when I am 
judging only from what info is available, I think that VID starts 
to shape nicely ...

BrianH: what Paul probably means, is why VID, why not Core .... but 
this one was debated to death here .... many ppl might not agree, 
but that is the only thing we can do about it ...

Where do you think the PARSE improvements are coming from? We are 
working on Core, because Core isn't good enough now to implement 
the new GUI. There have already been significant enhancements to 
the core as a result of the GUI work.

I think we're doing pretty well on catching bugs and getting things 
redone and simplified that are too hard to work with. Carl needs 
a lot of convincing in this department, and will ask me if there 
isn't a different way to do the same thing. He needs convincing that 
his code or methods are too hard to work with, but when there is 
a change, it's usually a great one, such as the recent addition of 
multiple draw blocks for the same style.

So I think he will want to interfere, unless it's a component that 
I wrote that works flawlessly, is perhaps 4-5 lines of code and I 
didn't mention any problems in developing it. :-)


We're two people catching bugs a little faster than Carl can fix 
them. When the situation becomes opposite, then probably there will 
be another release or more people added.

Not really the frames model, but otherwise you are correct. The capability 
to do this was already in the new model - Henrik's work just prompted 
the creation of some helper code to make it easier to do. We're still 
using the new model.

From what I can tell, the renderer displays fonts similar to what 
Freetype could produce around 10 years ago. We can do much better 
today.

I know.. what's with me and the "list" fixation? I wonder if it has 
to do with always trying to order my life. Actually, I thought that 
this is the first thing that my .Net friends are going to ask to 
see.

I think we still have some homework to do even in current state. 
What I think is suboptimal is timers. Fast View actions are still 
being a CPU hog. We discussed it several times, and I found some 
resources about timers. There are 4 - 5 types of timers in Windows 
itself, compatible with various Windows versions (or not). Windows 
is so much crap, that it does not support vertical blanking period 
=  forgot smooth not jerking not smeary animations, without DirectX.

It's funny that Maxim changed AGG to GPL for new development, then 
didn't do any.

I wish RT would hire Maxim as a consultant to do further development. 
Other companies have done the same (according to the site).

From Carl, in case those who are in the r3-alpha group are not noticing:


Test Strategy: I would like to build a group of REBOLers who can 
do different parts of this. For example, someone who will manage 
the discussion boards, someone to manage the bug tracker, someone 
to help with source archive, etc.

There are many other areas too.

Anyway, 
this week it will happen. So, if you can help now, or later, please 
let me know.

there is work to do .... doc has to import all the tickets from Altme 
bug tracker into curecode

I don't think there are screenshots - the live swing demo app is 
probably the best way to see/experience how the manager works - you 
don't need to install anything (you do need a Java VM, though)

Short VID3.4 status:

- Some extra formatting options in the DOC style.

- I added a numeric field today similar to the one on my old blog 
site for VID, except that this one took half a day to do instead 
of a week and was way easier to implement.

- Skin is changing appearance a bit, both to simplify and to extend 
its possibilities. This made it possible to build pixel-perfect text 
areas, lists and other combined faces, finally.

- Some bugs remain in the layout engine which make certain layouts 
look a little messy. Still not sure that MAX-SIZE is the right approach.

- Added CONTAINER to help produce aforementioned pixel perfect styles. 
As a bonus, such styles will have a common border, which we then 
can change in a simple way.

- Looked a bit at a CALENDAR style for a date picker, but decided 
that it is better to wait a bit with that to finish some other base 
styles first.

- No time table given, so I can't say when there will be a release. 
I can only say that we're moving forward all the time, fixing bugs, 
adding new styles.

- No DRAW fixes yet. I haven't seen Cyphre since 5th November. We 
can work around most DRAW bugs for now.

- Skin lacked a CONTAINER style to put things in. Lining up scrollers 
with text fields, lists, etc. proved to be problematic. When one 
looked OK, the other would look terrible. We had TIGHT, GROUP and 
PANEL, but none of those are useful as decorative containers. CONTAINER 
works llike the frame of a painting, and now all styles that use 
CONTAINER look almost identical and pixel perfect. It also allows 
me to build complex field styles, like a search field with icons 
or numeric field with arrows.

- MAX-SIZE: It's a combination of weighting and maximum size of a 
face. When you set MAX-SIZE, it will affect the layout of the face 
in code, even if you are nowhere near maximum size, something I would 
never expect such an attribute to do. Setting MAX-SIZE correctly 
is an annoying process of trial and error, can't be predicted and 
depends on the MAX-SIZE of other faces in the panel, which requires 
debugging and studying other styles or setting them manually with 
a lot of typing. There are also magic numbers, so sometimes you use 
a size of 4000 and other times 100000 to achieve similar results. 
This is really the only part of VID3.4 that I don't like. However: 
There are still bugs, so intended behavior may turn out to be much 
better than I think. I can't remember what VID3 uses, but I would 
guess it's a more traditional weighting model.

they are just not fixed yet. there are many things to do.

There are probably about half the concepts in place at this time. 
I still don't know if Carl gets a good idea and decides to do some 
changes.

All I can do is withdraw my offer to assist

It may come as a surprise because I have previously made it clear 
that I think the delays are very harmful, but I actually think that 
Carl's current decision to do a BBS is a good strategy

We really need to get to the state, where others can start to participate. 
And it will happen only if there is some kind of DevBase functional 
and Carl ready to upload R3 sources in there. I do understand the 
need for the existance of supporting infrastructure, but it can be 
done in parallel. We constantly wait for this or that, instead of 
releasing something ..

The other issue is that at the current stage of development, R3 needs 
apps. We need network apps to test the network infrastructure, GUI 
apps to test that, the list goes on. We don't need these to do a 
development release of R3, but we need to do a development release 
of R3 to get these apps made. You didn't think that Carl was going 
to delay the R3 release to write a forum, did you?

People are going to use REBOL to write forum software, or the many 
applications that do the same thing, technologically speaking. We 
will need to have test apps of that nature to make sure that apps 
of that kind will work. The reason that tool-builders use their own 
tools during their development process is to make sure that their 
tools work, and to get ideas. That is why other programming languages 
use tools built in those programming languages.

I have already had to skip a night of sleep because of the holiday 
overhead, and even then haven't had time to do any REBOL work. You 
are picking the wrong time of year to get impatient.

No matter ... R3 is irrelevant to what I do ... just trying to help 
move things along.

Just for the record, the Alpha group is noting but debate on the 
best way to do things....very focused, very dry.

ok - then the init function would do the trick with the draw commands 
changed to poke data into button faces.

Actually, Paul brings up the value of a release at this point: We 
need R3 apps for development to continue at this stage. We are at 
a point where we need people to write stuff that uses what we have 
so far so we can shake out the bugs. To do that, we need to get what 
we have in the hands of more people.

Naw, it's easy. Just think of the users of REBOL as being so stupid 
that they can't figure out how to solve any problem, but that they 
are the ones doing the work. The managers of our users need to be 
able to tell the users what to do with little understanding of how 
exactly our users actually do what they do. The programmers are the 
managers, the programs are the users. Our job is to mame it easy 
for the programs to do their jobs without requiring the programmers 
to learn so much about the internals that they are essentially doing 
the job of the programs. We want to reduce micromanagement.

Paul, yes, colors are experimental right now and definitely not final. 
rounded corners are a little harder to do.

Slider is really nice, but quite honestly - how often, if ever, do 
you use slider in your app to represent data? I would welcome more 
practical styles as tabs, tree-view, list-view (grid)

Do you think it would be too risky to develop with the Alpha? How 
different is the core?

for info, to convert an integer to a binary with struct! , we do.
>>str: make struct! [int [integer!]] [0]
then
>>str/int: 150
>> third s 
== #{XXXXXXXX}
which is the integer in little endian format

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Not at this time, no. I think that will be left up to a 3rd party 
to do such a thing.

http bugs??  Oh oh ... Gabriele has some work to do then :(

If I get to do it, sorting will be non-destructive, like LIST-VIEW. 
This means keeping a sort index. But that depends on how complex 
it will be. Carl tolerates only little complexity.

I think I need to re-read all those tight, panel, group, container, 
as those styles are similar and I don't understand why and when should 
I pick, when starting to do something ...

Henrik - do we have anything like "anchor"? I do remember, from Romano' 
s styleset resizing model, that you could anchor your element to 
some other, and it stayed that way. Maybe it is not needed with recent 
resizing model?

Cyphre is  not working on R3. He is working on Qtask. I don't know 
what exactly.. it was a joke a little bit. It has nothing to do with 
Carl and any BBS

I suggested to Carl to consider KDE 4 aproach. It was in development 
few years, and it seeemed like there is no end to this. So the team 
decided to cut some features for 4.1 and later, mark recent state 
as 4.0, and release it. They were criticised, but I do understand 
their motives. Those are mainly psychological - release, and never 
look back. Use current one. Are there bugs? OK, let's fix them, and 
go ahead ...

thought about it, yes. who will do it and how it will be done? don't 
know. if anyone wants to, I'm sure Carl will approve.

Claude all majors DB furnish api to do that , you just have to read 
documentation

but - to proceed in some unified system way, we would need Carl to 
return to Core development, after GUI is done. Without finalisation 
of main interfaces in R3, we still can't do much ...

Oldes: Is there something new with Rebcode?


Nothing new, but your requesting it means that you don't remember 
the problems the old rebcode had.

The bad news:

- Rebcode didn't work in R2, it was unstable and frequently crashed 
REBOL, very pre-allpha.

- Carl is unlikely to make a build with rebcode because of the above, 
and because he is focusing on R3.

- R2-style rebcode would be slower in R3 relative to the speed of 
regular R3, partly due to changes in function word lookup.

- Any rebcode dialect for R3 would be incompatible with R2 rebcode 
on a basic semantic level.

The good news:

- R3 has features that will make it relatively easy to add our own 
rebcode-like dialect.

- Even though the R2 semantics wouldn't be good, there are more tricks 
we can do to get more speed.

- The main reason that we don't get as much of a relative speedup 
for R2-style rebcode in R3 is that R3 is faster itself.

perhaps a work to do in the wiki

Perhaps you have noticed that in R2 there are 4 function types, 5 
with rebcode builds: function!, native!, action!, routine!. Each 
of these behaves completely differently on the inside, but are called 
the same on the outside. This is because each of these datatypes 
defines a different execution model. R3 will have allow the user 
to create their own datatypes, and that includes function types. 
All a datatype needs to do to be a function type is to act like a 
function on the outside. How it behaves on the inside is up to it.

Nonetheless, I am doing whatever I can to speed up regular R3 whereever 
it is reasonable to do so. The profiler is my friend :)

exactly :-) Ask sound gurus as Rebolek for details :-) But - Carl 
is very open in this regard. R2 currently uses wave win32API, and 
there seem to be a bug (which we noticed when we tried to do a video 
playback). Carl released sources, which are rather short for sound 
module. Maybe it could be fixed a bit for next 2.x release, if there 
is going to be any ...

just a joke to try to generate a coverflow animation.
REBOL []
angle: 10
angle2: 0
decal: 0x0
rot: 0
scene: [
	transform angle 50x0 1 1 0x0
	pen red fill-pen red circle 70x0 2
	pen green fill-pen green circle 85x0 2
	pen yellow fill-pen yellow circle 100x0 2
]
scene2: [
	transform angle2 decal 1 1 0x0
	pen red fill-pen red circle rpair 2 
	pen green fill-pen green circle gpair 2
	pen yellow fill-pen yellow circle ypair 2
]
img: copy empty: make image! 100x50
logo: copy logo-empty: make image! 200x100
locate: func [color /local idx][
	idx: (index? find/skip rgb to binary! color 3) / 3
	as-pair idx  // img/size/x to integer! idx / img/size/x 
]
view/new l: layout [image img image logo]
rev: false
for i 10 170 5 [
	angle: i
	change img empty
	draw img scene	
	rgb: img/rgb
	gpair: locate green
	rpair: locate red 
	ypair: locate yellow 

	either all [gpair/x > 35 gpair/x < 65][
		rev: true
		angle2: angle2 - 15
		decal: gpair
		change img empty
		draw img scene2	
		rgb: img/rgb
		rpair: locate red 
		ypair: locate yellow 
	][if rev [pair: ypair ypair: rpair rpair: pair]]
	change logo logo-empty
	b1: as-pair rpair/x 25 - rpair/y
	b3: as-pair rpair/x 25 + rpair/y 
	b2: as-pair ypair/x 25 - ypair/y
	b4: as-pair ypair/x 25 + ypair/y 
	draw logo [pen red scale 2 2 image logo.gif b1 b3 b4 b2 border]
	show l
	;*** PUSH ENTER TO ADVANCE
	input
]
do-events

be nice to do something like:

op? second [this + that ] 


and have it return true.  I know it is a word value now but I never 
understood why it was made word there.

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

I think this will be open, so someone can get to prettify it later. 
The mobile version is simpler to do so it's done first.

_Part_ of the problem is that altme server --> client channel (ie 
what is sent to each of us when someone posts a message) does not 
seem to contain charset information......I may be wrong about that, 
but I do not see it anywhere.

I have not idea if client-->server channel does send that information.

Peter....I'm confused....

Word, nor REBOL have anything to do with the problem....


Encoding problems happen on hundreds of websites (big, popular website), 
that do not use REBOL, and where Word is not the source.


I'll state again... we need strong clear black box logic that unifies 
all character maps (yeah, all).

WE need a single unified character system.

Another part of the problem, at least from the webpage viewpoint, 
is that each of us could be posting AltME messages in different charsets.


All the HTML emitters for AltME worlds that I know of (AltME's own, 
REBOL.org, REBOL.net) emit a single webpage file, so it can only 
have one charset.


To do it right, each post should be emitted as a separate document/frame 
item. Then they'll each have their own charset.....That's a lot of 
extra work. Let's hope Gabriele's solution (a utf-8 universe) happens 
before that becomes essential.

Yes. It's 2009 and we (as in industry) don't even get the computers 
to do *this* for us.

Just lemme know if the gurus ever want to do anything like that...