World: r3wp

Gabriele - how is lab50 thing different from simply creating new 
style? Or is just the specification of size the problem you are talking 
about?

So, Henrik, what's the status?

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 - you still feel no need for frames to return?

I've not needed it so far. In fact the last remnants of frames have 
been removed in the latest build.

Code example:

do %load-gui.r

files: read %*.r

view/options [
	tight [
		text-list files do [set-face ca read-string pick files value]
		scroller
	]
	ca: code-area
][
	title: "REBOL Scripts"
	columns: 0
]

Produces

http://rebol.hmkdesign.dk/files/r3/gui/036.png

That is why I suggest strategy of not adding new styles, but adding 
ALL subsystems. Because then you can see, if your upper layers do 
fit. Accelerators, focusing, disabling or other states combinations 
might change the view, if one single draw block is sufficient, or 
not ...

Henrik, that's cute! :-)

what is read-string?

oh no, I hope we did not go with read-string and all possilbe read-my-file-format 
instead of clean read/as and decoders aproach?

>> source read-string
read-string: make function! [[file][deline to-string read file]]

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

Today I was supposed to try to edit one corporate .swf file. Oldes 
suggested me some decompiler. There are items like - shape, image, 
font, text, button, frame, action, misc tags ( http://www.xidys.com/pekr/flash-structure.jpg
). It seems like flash (dunno if decompiled view is identikal to 
their proper IDE) is using kind of page-layout engine. Our corporate 
flash presentation is like browsing dynamic web. So far, with VID3, 
I can't see enough of  "rebol browser" in there, but more an app 
dev. platform. What is our equivalent of "page" - is it a 'panel?

'panel is the base for a window (currently), so it probably is.

It seems you settled for the final button look? Looks decent, at 
lest grey variant works. As for toggle, not sure color distinction 
is enough (colour blind ppl), and we should not add kind of 3D effect? 
(Button pressed, like in VID2?)

toggle is pretty noticable when you use it.

when looking at 35.png, the gradient is a bit strange - looks like 
2 color segments, instead of gradient ... is it supposed to be like 
that?

it might be a little strong

Henrik, is your website down? (The rebol.hm... one)

my wifi connection is pretty bad these days, so try again later if 
it doesn't work too well.

ok, Cheyenne had (again) mysteriously stopped. Please try again.

Oh, so that's T your home. OK

I'm in.

Henrik, you've got to be kidding me. Sweet! Can't wait.

neither can I. :-) lot's of work left, though.

Well keep working. I'll need a list-view : )

that's gonna be a while yet :-)

A few days, eh? Seriously, will the new vid help creating such a 
tool or is it basically the same in your estimation?

I have no idea yet as I'm only scratching the surface of this system. 
I'm 100% busy with skinning, so I have not had time to get too much 
into its features. But creating styles is very easy.

I'm not sure I want to port LIST-VIEW. I think it's better to start 
from scratch.

Henrik - I reread you list of things which are being worked on. Just 
wanted to ask, if so called "skinning" is not overrated? I still 
can see mainly aplication development aproach with VID 3.4 so far. 
Because - when you think more about browser aproach - what is there 
to skin? Each page usually might mean totally different graphics. 
Buttons, fields, etc. -  the forms, are just little subset of what 
is usually a "website". So - the button will always be the button, 
field will always be just the field. What users might be more interested 
in, is animations, transitions, and that can't be covered by just 
changing the skin. Dunno - tried WindowBlinds (http://www.stardock.com
) once in the past, and imo skinning is overrated - still the same 
thing expressed many times, while web = different aproach each time 
....

Skinning is the only way we'll get apps that look and act like the 
platform they are running on. It is how every major cross-platform 
application manages to look and feel fairly normal.

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.

I mean "every major cross-platform application" being made nowadays 
that doesn't have codebases more than 10 years old.

This includes the new MS apps as well, like Office 2007.

By the way, animations and transitions are a separate issue from 
skinning, and can be implemented independently.

Brian - we were never supposed to get exact OS look. The target was 
its own, decent cross platform look. If someone wants his app to 
look like native one, well then, but it is death for REBOL. And skinning 
is imo not going to solve the "act" part of the it?

There are a lot of features that have to work together to make skinning 
work, and those features are also useful for other reasons, especially 
when they work together well. Skinning is just a bonus ability. Personally, 
I want the ability to skin my apps, especially given my preference 
for dark interfaces - Henrik's stuff is great, but a little too grey 
for my tastes.

However, I am aware that my taste in interfaces is not shared by 
the community in general, and I would not it on others.

not it -> not impose it

Henrik told us in the past (VID3), that his skin looks grey, as he 
starts with 4 basic colors to prove the concept that "it works" and 
that later it can be done more colorful. I am against the grey interface 
overall. It is an old desing. Nowadays look at iphone, flash, Fedora, 
Vista - blue, black, colorfull is the trend :-)

btw - new debug featurs look interesting ...

it seems that Carl is trying to build really strong foundation to 
make development, debugging/testing and using the gui an easy enough 
task ...

Most major UI frameworks have theming support nowadays, mostly to 
support system theming - it's a checklist item when comparing frameworks. 
Not as much of a deal killer as a lack of Unicode support, but still 
what people expect. A clean, unified cross-platform look is a necessity 
to include, but making it the only look would reduce the uptake of 
REBOL. Many business apps need a platform integrated look, and many 
other apps want to establish their own identity (look at WinAmp, 
Chrome or the Apple apps).

Henrik has said in the past that his basic design aesthetic is to 
start with shades of grey and then add color as needed. This tends 
to make elegant, business-like interfaces. My aesthetic is more shades 
of black and white with color accents, avoiding blue as much as I 
can in user interface elements - more of a night person look. To 
each their own.

I see a middle ground - a strong foundation theme can transcend platform.

The middle ground is infrastructure - on that ground you would grow 
the UI you want, but you won't look at the ground :)

We will definitely be including a nice looking default theme though 
(we're still hammering out the concept naming).

My hope is that we can have generic themes that can be used by many 
apps, and made by a theme editor with minimal code. I would love 
to see R3 themes on the many theming sites out there already - good 
advertising :)

Brian - how one can add something like e.g. icon animation (as can 
be seen on an iPhone)? Can I still stay at styles level, not needing 
to rewrite/adapt low level? Hopefully so ....