AltME groups: search

Gabriele's resize model was a bit slow and difficult to understand 
- no offence to Gabriele, he just adapted the TeX sizing model. The 
problem is that the TeX sizing model was designed for desktop publishing 
and that doesn't require fast resizing, just complex layouts. It 
was overkill for UI layout.

BrianH: user-wise,  TeX model was rather easy to understand. It is 
a proven model. I hope Carl's model works .... when I can hear overkill 
for something which works, I fear underfeatured in Carl's terms ... 
I don't want VID3 to be built on compromises.

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

I never got the chance to try out make-gobs, but it did seem to solve 
a complexity problem on the DRAW level by giving it for example an 
internal resizing model, which is very important for properly made 
GUI graphics..

A simpler resize model is also easier to write code for - less fiddly 
for the less supreme programmer.

If you have a different goal, then you can be faster. For example, 
if you use something like my make-gobs for faces too, then you can 
compile a resize function that will be as fast as if it was hand-written 
(if you optimize well).

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

don't that will lead to a "Ho man that program is bugged it crash 
when i try to use it !!" and in fact the rebol script just needs 
the VID++ 2  turbo alpha ++ version

I'm agree that's a pity to abandon a work such advanced  and that 
demotive alot the comunity

gabriele worked hard to get his new VID and when it's all most complet 
Carl come with a better plan and trash out Gab's work that's not 
a good example to motive the comminuty to participate on further 
project where rebol content is directly conserned

As far as I can tell there are animation effects in it as well as 
a small suite of debug tools. Each source file is really small, around 
2-8 kb with a few going above 10 kb. Fully commented and very clean.

resizing is automatic, but buggy. there is a list of known bugs.

Carl says the animation system is a simple prototype.

aaaah, what a mixture of colors :-)

The GUI feels fairly quick, but Carl says there is still a lot of 
optimization and caching to be done. This won't happen until he feels 
the entire system works correctly.

the transitions right now are simply each element you see in the 
right side sliding into view one at a time. I've not yet studied 
how that works.

each style is a separate file

Now do we have yet a system with core R3 that is capable of running 
LNS?

Isn't stylize meant to infer "make style" whereas style is a "A style 
is essentially an informal class used to define the attributes and 
behavior of its face instances" t?

style can be a verb

but wouldn't using style for both the style objects and making a 
new style be a little ambiguous?

Personally, If I ever got around to using view, I'd be very happy 
if the syntax was make style! [ ....] or, looking at Carl's red box 
example..
red-box: make box [
	about: "A red box"
	facets: [
		area-color: maroon
	]
]

as for screenshots - those seem a bit "fuzzy" (?) to me. I wonder 
if it is due to jpeg compression, or is it caused by antialiasing?

Peter - make style! would mean, that style is a datatype. As for 
me, I have no problem with stylize vs style .....

that's a convention ... regarding!

Pekr, the fuzziness is due to antialiased edges hitting between two 
pixels, although jpeg compression makes it a bit more fuzzy. It's 
everywhere, it seems.

it was a joke!

More screenshots: http://www.rebol.net/wiki/GUI_Basics


Carl write, it's a prototype skin, and he uses jpeg (with artefacs), 
so those are probably just to feed the hungry ones.

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?

it's not a typo, but I don't know yet how that works.

Status: Fixing more bugs and I'm starting to work on the real skin.


So far, skinning is quite simple but not unlike VID3. It shares some 
of the same possiblities although there are certain restrictions 
in place to simplify and make it easier to understand. Unlike VID3, 
gobs are prearranged, so there is a single DRAW gob and a text gob 
on top of it and during skinning, I'm not even aware of the presence 
of gobs. If the skin does not work, the face is invisible.


I've been told to hold back on using VID until Carl has tried building 
some apps and dialogs with it to eliminate usage problems.


Pictures are trickling in on the aforementioned URL once in a while. 
:-)

That I still don't know, but I'll show you a fontize example. Fontize 
is like stylize, only for fonts.

Fontize is quite a nice way to separate asset information for the 
skin away from the skin itself. This way you know where all font 
styles are. Besides, fonts in R3 are more complex than in R2 as there 
are more options.

I would like to know, what ppl in general here find as being a nice, 
but still practically useable skin ....

I make most of my decisions from how physical buttons, knobs and 
materials appear, how light affects them and try to approximate that. 
I don't have a plan for the finished look as I prefer to make things 
up as I go along and look at the whole thing when it's done to see 
if some parts don't fit together. Then I change the remaining parts 
until they fit together. But the point is not to approach it as a 
physical device as a whole, like this:


http://www.synthtopia.com/content/wp-content/uploads/2008/02/nusofting-drum-machine.jpg


It's only to help discern between different types of widgets in an 
interesting and recognizable way. Since the beginning of MacOSX, 
I've looked at their UI and wondered what materials it would take 
to build their user interfaces, if it could be physical. There seems 
to have been careful thought about physical appearance or they actually 
built a real physical model of the user interface as a starting point. 
I think that's one part of what makes it interesting and attractive 
to look at.


Before OSX, UIs were largely either like the drum machine or they 
were mostly cartoony symbolic abstracts of real life elements, like 
AmigaOS, Windows or early MacOS. The original VID fits under that 
category too.


With the VID3.4 skin, I wouldn't mind if a button reminds you of 
the button on the photocopier or on the dashboard of your car in 
a realistic way, without being impractical.

Real-life does not necessarily mean attractive and cool, eye catching. 
E.g. latest AmigaOS 4 is plain ugly and not pleasant ...


Well, it is exactly opposite of what I meant. :-) OS4 is a cartoony 
user interface. I don't know where they started from when they designed 
it.

Anyone can make a UI (just look at the billions of Linux distros 
out there), but really few can make a lasting, memorable, useful 
and beautiful UI.

Reichart, as far as I read, they tried to make it work on the worst 
possible TV set they could find, so that's definitely a factor for 
the original color choice. But I wonder if they grabbed the look 
for OS2.0 and up from NeXTStep.

yes, it's perhaps a little too mild. there is also a bug with 'up 
not being followed by an 'over, but Carl is fixing that.

I think that the skin strategy should be to make it easy to make 
and apply skins, get Henrik to make a good default, and then let 
third parties create good new ones. There are whole web communities 
devoted to reskinning apps - if we can make a skinning infrastructure 
that appeals to them, we win.

Pekr, having a single draw block is why they are not really frames. 
All that happens is that a state is stored as a word, in this case 
'up 'down and 'over (as far as I've observed) and then you make the 
necessary modifications to colors or other parameters to the single 
draw block. This happens inside ON-DRAW.

I'm going to post a bit of code now. The word FRAME does appear in 
it, but this appears to be from a previous version which was frame 
based. Carl has not yet come up with a new word, so don't be confused:

Pekr, no, face/state/frame is only a word, like 'up, 'down, 'over, 
etc.

Pekr, we'll see how that works later, when I get to build a small 
DRAW editor.

'Fontize doesn't grab me on a first reading either. Carl always thinks 
hard about words, so he may have ruled out 'stylesheet and 'fontsheet 
system, or something like it. Not sure how ize-ing things will work, 
be he may have.

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.

If you write a number without a decimal point, it's an integer datatype. 
With a decimal point, it's a decimal datatype. You can use either 
in many functions:

>> for i 1 2 1 [print i] 
1
2
>> for i 1.0 2.0 1.0 [print i]
1.0
2.0

Rebol[]

fibonacci: func [{Makes a list of fibonacci numbers and stores them
	to a block called fibonacci-block.} loops [integer!] {Number of 
	iterations to run}
	] [
	fibonacci-block: [0.0 1.0]
	count: 0
	loop loops [
		addend-1: index? back back tail fibonacci-block
		addend-2: index? back tail fibonacci-block
		new: fibonacci-block/(addend-1) + fibonacci-block/(addend-2)
		append fibonacci-block new
		count: count + 1
		print count
		print new
		]
	Print fibonacci-block
	write %fibonacci.txt fibonacci-block
	unset fibonacci-block
	halt
	]
Print "Type fibonacci [# of loops] to make fibonacci-block."
halt

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?

By the way it looks a lot like a Java GridBag.

So you think that a Panel is an invisible container?

I think adding integers used to produce a decimal, when it overflowed. 
There were problems caused by this, and discussions followed, so 
it was changed to the current system.

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.

From re-reading the Docbase page, it seems that both panels and groups 
may be visible as they have styles:


Panels are implemented with the panel and group styles. You will 
use these two styles together to create a wide range of layouts.


I don't think that I'll try to clarify the DocBase entry just yet 
though.

Gregg, I think what you remember about coercing to decimal is that 
if you type a number greater than maxint it gets loaded as decimal.

Is it really one gob with a gob style face placed upon it? Isn't 
even something as simple as :
panel [
  button "Start"
  button "End"
]

at least 5 gobs?

Currently, PANEL produces a background along with a border. That's 
why there are a lot of rounded borders in the first screenshots. 
Due to a bug (?) in the layout engine, PANEL must have a draw block 
assigned that fills out the background with a neutral color.

GROUP behaves as follows:

- No background

- When not specifying elements in a group block, they layout vertically.

- When specifying elements in a group block, they layout horizontally.

- When specifying a number for the group block, each element lays 
out horizontally until the number is reached and then a new row is 
started.

Differences from VID3:


- There is no concept of rows and columns. Elements of uneven sizes 
will uncritically be laid out right next to eachother. I've not yet 
discussed with Carl whether this goes in or if there is a different 
solution. I've observed code for grid management in both GROUP and 
PANEL and a facet reading "grid: true", but it seems not to be working.

A couple of articles I found interesting about the future of interpreted 
programming languages. 

http://weblog.infoworld.com/fatalexception/archives/2008/10/virtual_machine.html

http://weblog.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/10/13/42TC-dynamic-futures_1.html

VM, JIT and access to other programming languages libraries is the 
future...
Maybe Rebol 4 ?

There is no concept of rows and columns.
 <--- this was a bug and has been fixed.

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

It's very difficult to produce anything useful with a darker color.

That would complicate the code a bit too much. We can only recommend 
that people don't use dark buttons. :-) It's easy for the user to 
adjust anyway.

Carl's now describing a bit sizin model in following chapter - http://www.rebol.net/wiki/GUI_Panels

That Panels doc is a work in process.

It kind of made point, when Carl posted once in two months. But now 
it is almost daily, so maybe I will stop it, to not flood here. Surprised 
a bit by low number of reactions. I thought ppl will be more interested 
in new GUI and how it starts to turn out ....

I hope the subject of the example, a colour picker, isn't an indication 
that the new Rebol GUI isn't going to native dialogs. Windows, Gnome, 
KDE and Mac OS X all have native colour pickers don't they?

It's a function of some type defined lower down

what is "when [enter]" then? 'enter being just a function argument 
name?

i don't like at all the lab50 thing. that will NOT allow localization, 
just to make an example. i consider having to size things explicitly 
a HUGE mistake and i will never say it loud enough.

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

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.

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

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?

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

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.

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

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.

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.

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

Which is kind of appropriate, because every time I edit Carl's code, 
it makes me feel like I'm painting a moustache on the Mona Lisa. 
:-)

Henrik ... it was a joke ... at all these *ize words

Graham, mine was a joke too :-)

My opinion on skinning in general: I think skinning is something 
that has been gravely abused over the years. The last time I enjoyed 
skinning was with MUI on the Amiga because MUI was made for skinning. 
It was simple to get a good looking user interface without compromising 
usability or functionality. Nowadays we try to skin OSX and Windows 
in ways they were never meant to, and you feel it when using it. 
There are slowdowns or functionality is sacrificed. When you flip 
through a skin catalog, 99,9% of them are terrible junk and it's 
difficult to come up with your own.

I plan on trying a very different skin after this one.

Yes I am. So far I've been doing code auditing and cleanup while 
I get a feel for the overall system. The design is really cool, though 
some parts are still under construction. Not modularized yet, nor 
should it be until it is more finalized. Most of the core design 
is pretty stable.

BrianH: that is cool! You already did good job for DevBase. Now it 
would be interesting, if you would thought about DevBase VID3.4 :-) 
Maybe a good testing app to start with :-)

A new DevBase is still intended to be a testbed for REBOL technologies, 
including the new GUI and LNS.

A more modern GUI for devbase would be nice

there has to be a few exemplars for the rest of us :)

I can't go into the core changes right now because some of them aren't 
finalized (and it's 4am here), but here's a teaser: SELECT on object! 
acts like GET IN, but much faster. If the argument word is not a 
field in the object, #[none] is returned - no errors, no undefined!, 
just like with map! values.

that's a custom widget