World: r3wp

But there are no means to control them. You must provide them yourself 
(1-2 lines of code).

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 ...

Pekr, it's trial and error. There's no guarantee that I won't come 
up with something better later. Right now I'm redesigning text field 
to make it work better in more situations.

The symbols, the rounded triangle and the octagon are inkscape based 
and yes, you can see the scaling errors there, which are not apparent 
in the circle. And that is exactly why I want gradients in lines.

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.

OK, and for your default skin, which will be included, do you plan 
other than grey background? :-) I know it can be probably easily 
changed, but the thing is, that sometimes buttons or other widgets 
might not work with some background types ....

There will be more tests on backgrounds later.

Are we any closer to "more ppl being involved"? :-) It is few more 
weeks from such statement. Not being impatient, just asking .... 
it seems that there is still major design work being ongoing, and 
now it is dialogs ....

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Question to BrianH probably: does current design allow "iterated 
faces", like in VID2?

I think there are a few more problems to solve right now, before 
we can get more people on board, otherwise there would be too much 
noise.

Pekr, I think iterated faces are gone, which is a good thing.

Minimalized faces and the gob model are partly designed to make iterated 
faces less necessary. We haven't needed them yet.

Re-did scrollbar for the third time. It gets easier every time. :-)

the subject that worries me the most is how is managed the caret 
handler

I have not studied that, and I don't think that part is complete 
yet.

I fear that this is not done better than in R2.

so that we can't mix and edit easly draw blocks wich contain text

i hope i'm wrong

all depend of the efficientness of caret-to-offset/offset-to-caret 
functions (or their equivalent).

if the can deal with richtext block or draw blocks, we are daved. 
If they can't it will be ever a mess to build richtext editors.

*we are saved (not daved)

From Parse: Scrolling panels was greatly sped up a couple of days 
ago. I noticed some extra refinements to some internal updating functions 
to omit excessive redraws.

cool. Henrik is probably referring to my parse group post, stating 
that public alpha button-colors.r scrolls rather slowly ...

most slowdowns are because of excessive redraws, so as we move along, 
those are weeded out and the GUI speeds up.

redraws are caused by VID, or you mean excessive redraws non optimisations 
in View engine itself?

non-optimisations

oops, misread that sentence

redraw slowdowns in VID of course, but they are due to non-optimisations 
in VID. :-)

My sentence is english wise confusing in itself, so :-) hmm, I thought 
that redraws, correct clipping (decision what needs to be drawn and 
what not), is View's job. IIRC we have some helpers in View2, via 
'changes field or so ...

Do we have something like PUSH/POP for draw, or low level caching 
of pre-rendered stuff?

Yes. And it's all turned off right now. :-)

So we have it, and it is turned-off? :-) Why? :-)

Basic rule of programming:

1. Make it work.
2. Make it work fast.

:-)

1.5: Make it work correctly

3. Make it bloated

Maarten;  Not to purposely pollute the REBOL3 discussion; but isn't 
rule 3, a Rule of Management?  Not something Carl (fortunately for 
us, or many rebols come to think) prescribes to.  Anti bloat being 
part and parcel of our long winter of wait for REBOL/3?

Yes, new VID starts being bloated. It went from 13KB compressed to 
22KB so far, and I start to think of buying new harddrive because 
of it :-)

Bloated is the opposite of working correctly, as a clean design is 
one of the design requirements. So, 1.5 negates 3 :)

Maybe Maarten meant it the other way - simply put - first things 
first. If Carl would design it with the whole VID scope (focusing, 
many other styles, adding other subsystems from the very beginning), 
the design could be shifted, and hence bloated?

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 ...

I don't know why Carl needs to work on a VID3.  Why not just release 
and distribute VID as an addon.

The plan is to get the core concepts and infrastructure done, make 
enough core styles to make sure the infrastructure works and make 
DevBase, and then let the community bloat it with their own styles 
at their option. Modularity means that we don't have to ship a monolith 
anymore.

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.

In that case BrianH, then it doesn't sound like just VID is at work 
here.  Sounds like the underlying VIEW component is still under development.

Any talk of timeframes?  I know that is usually a sensitive subject.

... as for me, I like View, so I am OK with it. But as I already 
said - imo after the VID, Carl should return to Core, to get it to 
beta releasable state, and upload host source codes to DevBase, as 
promissed. I am for less functionality for 3.0, but beta code. Untill 
that happens, Carl is the only one working on R3 ...

I think noone will provide you with any timeframes. But, I read somewhere, 
that soon (whatever that means) there will be more ppl included in 
testing of VID 3.4

I plan on having a very robust development effort once we get a beta 
release.

No, not just the underlying View component, low-level system enhancements 
and even mezzanines that can be used for non-graphical development 
- Core changes. The work on the new GUI is generating benefits for 
people who don't need a GUI.