World: r3wp

why debug red lines can't be seen, if full gob size is utilised? 
Can't it be layered inserting new gob into gob/pane?

It's not supposed to be seen, because otherwise I wouldn't be able 
to see the lines that are supposed to occupy those pixels by the 
style itself. The debug function is activated like this:

view [button "hello" debug]


and the red box appears in the face, not around it. The red box stretches 
to the very edge of the gob, so you can see where you draw.


The box is generated in the same draw block, by simply inserting 
a red box in the beginning, if the debug flag is enabled.

Having this box, helped us solved numerous layout bugs.

Yes, but why not insert it at the tail then? Because, when not seen, 
it does not work for you, no? What about styles, which do utilise 
the whole gob size?

Read the first line in my response for your first question. :-)

Anyway - I was surprised by addition of debug modes. It will greatly 
improve situation over R2 VID.

... when you debug, you don't want to see your lines that are supposed 
to be there :-)

The second question: Some styles will occupy the entire gob size, 
yes. That's no problem. The red box is mainly there to display where 
the border is on the gob. Nothing else. I had great trouble aligning 
styles without it.

your site's down ....

Pekr, correct.

I see, perhaps it's one of the mysterious Cheyenne crashes.

BrianH: As I understand UCS-2 cannot be used to encode characters 
outside the BMP. It is a full subset of UTF-16. It should not cause 
problems with WIndows Unicode API except that it would not be able 
to display characters outside the BMP. (It would instead include 
 an non-displayable character for each 2-bytes returned by Windows.)

The problem would come from the Windows API returning characters 
that can't be handled which would appear to REBOL as 2 non-displayable 
characters, or REBOL code inserting characters inbetween double characters 
by accident, or copy grabbing partial characters.

Henrik - re your new screenshots - calculator - what is the reason 
grouped buttons of math operations are not precisely aligned vertically 
(at the bottom) as the num pad? Is it a bug in layout, or is it like 
it should be?

e.g. numbers 68, 69 ....

Pekr, illustrations for Carl to use for fixing those alignment bugs.

Henrik - is the gradient type/structure the same for the above mentioned 
calculator buttons and for the normal buttons in another screenshots? 
That calculator one looks good. But maybe it is because of white 
text color ....

The button style is called MINI-BUTTON and is derived from BUTTON. 
It's meant to be used in groups and confined spaces. It took about 
5 minutes to write. The font is custom for this application.

BrianH, can you talk about the set [a: b:] issue and what it means 
for us?

Brian: same as there is a conversion between the Linux UTF-8 APIs 
and the internal 16 bit array, there is a conversion between the 
Windows UTF-16 APIs and the internal 16 bit array. In the same way, 
we can eventually support 32 bit arrays and convert those UTF-16 
strings that can fit into it to just 8 bit arrays.

Gabriele, cool, I was just concerned about speed. I suppose calls 
to external APIs are likely to be less frequent than internal manipulations, 
and UCS encoding would make the internal code faster. Either way 
I'm sure that it will be handled :)

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 :)

There are going to be more of these fixes in the next build. Stay 
tuned for more treats :)

Thanks for the info, Brian.

Brian, once Carl told me that SET allowed only word! in blocks because 
other types were reserved for future "dialected" meanings. But, I 
guess, we're giving up on that?

BrianH: we have one special set-word notation in R3 'foreach. Hopefully 
it is not problem to explain this one ...

Gabriele, noone came up with an appropriate dialected meaning over 
the years, unlike with FOREACH. So, unreserved :)

Pekr, since the words and set-words in the word argument of FOREACH 
get bound locally to the code block, they can't refer to local variables 
in an outer scope even if you wanted them to. So FUNCT has no effect 
on FOREACH.

A bit of status:


- Carl ran into a bug in the AGG C++ code: "draw 10x10 []" in the 
console will crash R3 and it's a tough one, as it might be compiler 
related. Not fixed yet.

- Some of the stuff that BrianH has talked about above is now implemented 
in a new build of R3 as well as some additions to MAP!.

- My ramblings on DRAW has caused me to pause on skinning until I 
can get a clear picture of whether the problems will be fixed. Otherwise 
I'll have to redo a lot of work later on. I experiment with compound 
styles instead as well as some simple color palette tools.

- It was decided that popup graphic elements are to be done in separate 
windows for greatest flexibility. No code done yet though.
- No talk about overlays or drag'n'drop yet.

Thanks

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?

- It means elements that are floating above the layout at any position.

- Popups are windows, popup menus, bubble help and other graphic 
elements that may extend over the edge of the window.
- I have no idea what can be fixed or if it will be fixed.

Cyphre's in now, so we'll see.

http://www.rebol.com/article/0377.html- R3 project status ...

I miss plan for inclusion of important things I named in the past 
... releasing new VID without them is imo a fatal mistake ...

Well, that's what comments in the blog and here are for. Please provide 
a list of things you consider important and we can discuss the list 
and get them included, or come up with alternate features that do 
the same thing but better. Don't assume that any features we already 
have will conflict with what you want. Feedback is king here.

I posted in on r3-alpha - I can repost to blog, as I expect more 
wider audience comments in there ....

I'll look there unless you want to have the discussion here.

The "list of widgets" post?

yes, list of widgets ... we should not release without widgets like 
tab, tree-view, basic table (list-view), accelerator keys (needing 
redesign of all relevant styles imo, because rich-text will be needed), 
tabbing support. VID2 show stopper was missing more advanced styles, 
at least above mentioned. Those are needed for basic prototyping. 
Newcomers will not be able to produce them themselves. Most ppl would 
prefer such things instead of fancy color requester etc.

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.

lested -> listed

This is good to know, and imo Carl should update his blog. For many 
ppl over the years, the real show stopper was missing styles. The 
blog article almost sounds like we would be finished ...

The new GUI is going to be extensible with new styles. No list of 
styles will be sufficient for everyone, so we are enabling and encouraging 
developers to make their own. For instance, I would like some styles 
inspired by the Office 2007 UI: ribbons and contextual toolbars. 
I know whole applications that are less complex to implement than 
those styles, so I would not expect them to be included in the core 
release at first.

Nonetheless, some design decisions and features are getting somewhat 
finalized as part of this process, so you weren't off in that.

What is the most difficult design issue nowadays regarding VID (hence 
e.g. not decided)? Is it low level draw changes, or implementation 
of some subsystems?

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

Well, first it is upon decision, how draw should evolve at all :-) 
But it seems to me that some of you guys are asking for more flexibility 
at pixel level ....

What happened to the stuff Carl was working on to increasing the 
power of the GUI by making it more webpage-like - by incorporating 
services into the widgets? I have not heard any recent talk of these 
ideas...

Not working on that part yet.