AltME groups: search

so a text-list is now called a "style" ?

So, I guess I need to wait a couple of months ....

yes, probably a good idea

I presume I can change the font used to a monospaced font ...

you can, if you can find where the font specification is used in 
the list, but you want to create a new style that uses that font.

noob question ....  how can I define a function that accesses a field 
before the layout is created?

so my area ends up with a row of 

c: s: c: ....
before any real text appears

Is there any easy fix to trap Control-C in a text field ... so that 
it doesn't kill r3?

though I haven't played around with the latest versions...  and its 
been a very long time, so it could be that I tested it just before 
my vista install crapped out.

but the true thing is windows XP have  10  years now it's more than 
deprecated OS. If the font probleme on R2 cant't be solved ok i'm 
ready to wait other year to get a R3 draw/font relation working perfectly 
everywhere. The lessons of area-tc are:

1) it's possible for AGG to deal text rendering evolved at a low 
level (perf are great  on R2 and that's convincing)

2) Since draw wasn't made to handle such an extensive use of the 
draw/text instruction  in R3 we have to make the AGG mode adapted 
to block of text handelling the first idea and the main  boring thing 
to have to deal in AGG text rendering is the positioning of every 
block of text. We need a way to retrieve the position of a texte 
on screen.  

3) to be better and faster AGG should be less verbose. I know that 
it's possible to save lot of space in the draw block

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

Maybe it's even possible to mix the current and simple "add action 
to widget" pattern with such a event based system.

I have used such an approach in one of our apps.For example I have 
three tables, that depending on the app state, show different columns 
and data. So, when app state switches this will trigger the change 
of the tables.


And other example is changing the language just where you are. No 
need to re-enter the current GUI etc. There will be just a change-lang 
XY event send.

Wasn't Max proposing a message passing gui in one of his various 
liquid thingies?

liquid is a message passing engine, but its complex to use in guis 
as-is.  it can be done (as I shown a few times) but requires a dialect 
or api over it to manage it.

the advantage is that its a generic engine... and can be used to 
link up any aspect of an app. not just its "actions"

exactly what I think.  keep it simple for now... once liquid is revamped 
for R3 we can see how I can make a module to add it so view 3.4, 
just like I did for view R2.

Carl's original goal for the GUI was to make it so a child could 
use it. We should not deviate from that goal. That's part of what 
Rebrowse is meant to do. I don't want to risk a forking of the GUI 
work.

I don't mind advanced features at all, but we must be careful not 
to make the GUI difficult to use from the outset or having to place 
the user into a specific mindset, when starting to learn it.

exaclty. I think that VID3.4 is designed in a good way, let's first 
see, if the architecture provides us everything we need ...

to me VID always very easy to use.  making it pretty & dynamic ... 
well that's a bit (a lot ;-) more painfull.

I think it's possible to make it strong for industrial strength applications, 
without making the usability a hindrance. I also wouldn't want to 
lose the ability to write a GUI in 2 minutes for your boss to use.

We all agree on that, but I just want to raise the point that a lot 
of the short commings in view are based on some serious issues in 
VID.

view is already much more powerfull now, but I feel that the current 
design is like going half way. 


instead of having a totally open level 1 (gfx engine) on which level 
2 (view) and level 3 (VID) is built, we have level 1.5 and level 
3

and I mean within REBOL, not within C.

Most of VID's serious issues come down to event handling (solvable 
now) and incompleteness (also solvable, just a bunch of hard work) 
and missing features, like keyboard navigation (already solved that). 
The VID extension kit makes VID much more scalable, simply by finishing 
the work that Carl set out to do. It's easier to write large apps 
because styles are more uniform, and you have more powerful features 
and adherence to face accessors, rather than relying on face hacking.


Building those features into V3.4 by default, and you have a killer 
UI system without sacrificing usability.

themes are a 2 function addition, and localisation would be a single 
function to add.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

add a closing ']'. An example app is:

blk: copy []
foreach word words-of ctx-rebgui3/cursors [
	append blk compose/deep [
		text (form word) handler [

   on-over: make function! [[event][cursor (ctx-rebgui3/cursors/:word)]]

   on-away: make function! [[event][cursor ctx-rebgui3/cursors/arrow]]
		]
	]
]

display "Test Window" compose [
	text 83x10 rich [size 36 center red "Reb" black "GUI" leaf "3"]
	after 5
	(blk)
	return
	bar
	reverse
	button "Close" [undisplay event/gob]
	button "Open" [
		display "Alert" [
			after 1
			text 50x5 "Some more text."
			bar
			reverse
			button "Close" [undisplay event/gob]
		]
	]
]

Even better, I'll upload it as a script to my website. Oh, and the 
above app example is missing an important line at the end:

	wait system/view/event-port

Yes and no. Yes it's going to be as minimalistic and bloat free as 
before ... no as I'm aiming for something that allows seperation 
of form and function. RebGUI has a number of limitations that under 
R2 were problematic to resolve but under R3 are doable.

Nice Ashley. Waiting to see RebGUI in R3. Your project could be a 
big step forward for REBOL

Ashley - maybe you can "just" write a low level layer of RebGUI3 
in such a way, that upper layers (widgets) code will require no change 
to its code? Having RebGUI available for R3 could boost R3 usage 
...

Reposting from R3 chat (which seems a bit quiet lately).


I've been looking at the rich text gob! functionality and it seems 
the following dialect commands are supported:

	anti-alias logic!
	bold [off]
	italic [off]
	underline [off]
	size integer!
	left|center|right
	drop integer!
	font object!
	para object!
	caret object!
	scroll pair!
	string!


Are there any I've missed? Any doco on this yet? I havn't figured 
out how to use drop or caret yet. Anyone have any working examples 
for these?


A design question: is there any reason for retaining font and para 
support given that we could move the few remaining unsupported words 
out of those objects and into the dialect itself? (e.g. have the 
dialect directly support font names and valign words).


Also, it would be nice if we had control over the default font name, 
size and alignments [at the very least]. Perhaps a system/view/text 
object?

I think that's a product, so it's better with an R3 specific group.

Henrik: that would surely increase confusion by many levels. a great 
idea :P

Create a subheading of Community/Libraries (621) and upload it there.

Got caret working, but it's overly complex IMHO, as in:

s: "A bit of text."

c: make object! compose/deep [
	caret: copy [[(s)] (tail s)]
	start: copy [[(s)] (at s 3)]
	end: copy [[(s)] (at s 6)]
]


show append clear system/view/screen-gob make gob! [text: [s caret 
c]]

regarding the caret obect:

the CARET, HIGHLIGHT-START and HIGHLIGHT-END fields must be defined 
as block! of the following format:
[block! string!]


the first block! value must be the gob/text block! at the index position 
of the text element


the second string! value must be string of the text element at specified 
position


You cannot just copy the first block as in your example above. You 
have to set the block to the position where the text element really 
is in the dialect block(this way the text engine can use the index). 
This part is a bit tricky but it was decided after long discussion 
with Carl. I proposed to use simple integer! for the index, but Carl 
wanted it to be this way which is easier as you can manipulate the 
block index easily without the need to use INDEX? to get the integer.

Thanks, your example (and explanation) makes it all clear now (I 
only tested/debugged with a single string before).

Is the lack of a table face ( or whatever the new jargon is ), a 
reflection of the difficulty of building it, or some other issues 
with the gui engine?

Weighting happens by "pushing" other elements aside, like soap bubbles 
pushing against eachother. The bigger the element is, the more it 
pushes. But space is also divided between the number of elements 
available in a given group, so a group of 5 buttons takes a little 
more space than a group of 3 buttons.


That gives the problem you see with strange spacing before and after 
the vertical scroller, because it's size is not big enough to provide 
push. and the other elements are too small to provide enough push. 
Combining the size of the face and the push factor is why resizing 
is broken.

But there are more bugs in it than that. If you push too much, the 
elements overflow and will be clipped by the right and bottom edges. 
Furthermore, the calculation of space to the right edge and bottom 
edge is also broken. It's almost impossible to predict in your head 
how the layout will look.


I'd like to replace the resize engine with something more concrete, 
perhaps with springs instead and fixed pixel sizes (oh, maybe similarly 
to what the VID Extension Kit does) or depending on whether Carl 
get's started again with his specs list (which I unfortunately can't 
locate). I hope we'll get to start this month.

Then we can ask Carl for permission to put it in a community repository 
in DevBase.

I see R3-gui has a gob called 'code-area which uses a monospaced 
font.

I could use text-list instead of table if that can be used with a 
monospaced font.

Also, I've read thru the docs ( but not the sources ) and it's not 
documented on how to create a GUI event

That's the false positive I was complaininbg about in Advocacy. You 
can't dispute it without paying them money. If anyone has a commercial 
AVG support contract, please dispute that.

Glad of that, since if one showed as a false positive based on a 
signiature scan it's likely that they all would.

It's possible that the compressed mezzanine data cooincidentally 
included a sequence of bytes that matched some signiature of someone 
else's code, which wouldn't matter to us since that code is decompressed, 
not executed.

I may try to ask a friend who works at AVG, but I cannot promise 
anything.

It looks I can use a monospaced font in a text list by changing the 
text-list-box face/text-style to 'code instead of 'list-item ... 
but quite unclear to me how one does this easily

Is there an easier way to do this than this?

    code-text-list: tight [

        about: "List of selectable text lines with scrollbar using a monospaced 
        font."
        facets: [
            max-size: 150x3000
        ]
        options: [
            list-data: [block!]
        ]
        content: [

            text-list-box :list-data :area-color options [ text-style: 'code 
            ]
            scroller
        ]
        actors: [
            on-init: [
                if select face 'reactors [
                    extend face/faces/1 'reactors face/reactors
                ]
            ]
            on-set: [
                set-face/list face/faces/1 arg
            ]
            on-get: [
                get-face face/faces/1
            ]
        ]
    ]

I think it's a little potentially confusing that 'options in a style 
refers to the stuff that follows a widget when it is used, but the 
options keyword following the widget refers to the facets

you wouldn't need to write it often!  Unless you were writing a lot 
of your own styles

vocabulary shows that param, parm, is a regular english word ....

so that you know that text-list takes a block

Make sure the word is not used anywhere else in the R3 GUI. Font 
changing, AFAIR is a little cumbersome. In the R3 GUI, fonts are 
a resource, similar to colors, certain draw blocks or materials.

we are free to make suggestions... but it would be nice with a place 
to store them.

settings is a better word than options because options is not really 
an option ... since they already occur.  You are setting them.

not a good argument if it leads to confusion

there is a distinction between standard parts, which are inherited 
throughout many faces and private parts for each face instance.

I have no problem with it, perhaps because it's also a Danish word. 
:-)

I really don't understand the need to invent a new vocabulary

when I read through the sources (which you can get, properly formatted 
and documented through R3 chat), I can see there probably needs to 
be a better distinction between 'facet and 'faced.

a face is comprised of parts
vs
a face is comprised of facets

a face is an object, and what does an object consist of?

facet 


. One of the flat polished surfaces cut on a gemstone or occurring 
naturally on a crystal.
2. Anatomy A small, smooth, flat surface, as on a bone or tooth.

3. Biology One of the lenslike visual units of a compound eye, as 
of an insect.

4. One of numerous aspects, as of a subject. See Synonyms at phase.

I don't agree. I've built quite a few styles in R3 now, and I've 
not once mixed up FACE and FACET, particularly because the path FACE/FACETS 
exists. I find it to be a pretty natural word to use.

Aspect

1.. appearance to the eye; visual effect the physical aspect of the 
landscape

2. a distinct feature or element in a problem, situation, etc.; facet 
to consider every aspect of a problem

3. the way in which a problem, idea, etc., may be considered to consider 
a problem from every aspect
4. a facial expression; manner of appearing a severe aspect

5. a position facing a particular direction; outlook the southern 
aspect of a house

6. a view in a certain direction a good aspect of the village from 
the tower

7. a surface that faces in a given direction the ventral aspect of 
a fish

8. (Spirituality, New Age, Astrology & Self-help / Astrology) Astrology 
any of several specific angular distances between two planets or 
a planet and the Ascendant or Midheaven measured, from the earth, 
in degrees along the ecliptic

9. (Linguistics / Grammar) Grammar a category of verbs or verbal 
inflections that expresses such features as the continuity, repetition, 
or completedness of the action described Compare perfective [2] progressive 
[8] [10]
10. (Life Sciences & Allied Applications / Botany) Botany

a.  the compass direction to which a plant habitat is exposed, or 
the degree of exposure
b.  the effect of the seasons on the appearance of plants
11. Archaic glance or gaze

Aspect is also talked about in aspect ratio, which could become a 
function in R3, like it is in the VID Extension Kit.

I don't agree... but then again, I've written a lot of styles. It 
may appear confusing to beginners.

they are a big jumble of experiments. not a good place to start from.

Pekr, Carl's VID uses a stack of identically sized GOBs that each 
perform separate tasks: Skin, text, debug. Each GOB stack makes one 
face. When designing a style, you never need to touch GOBs at all.

GOBs are a means for rendering faces at a very low level. Just consider 
it like R2/View, where you, instead of having a cosed up system, 
can tinker with the inner workings of the FACE object in relation 
to View.

OK, a meta-gob to recreate R2 functionality (given that a gob! can 
only do one thing)? I understand why layout was a "face factory" 
under V2, just thought we'd naturally move to a "gob! factory" approach 
with R3. I'm not being critical, just trying to understand why we 
still need the concept of faces under R3.

Ashley, yes, we just have a bit deeper abstraction layer in R3. Things 
like MAKE-GOB can still be useful for other things.

I put a warning on the document ...

the more I look at it the more I think settings is a better word 
than options

looks like 'comment { } is not allowed inside a stylize block

Is that a bug?

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

Graham, STYLIZE is a dialect, so it would need to support comments.

I see Graham is already submitting GUI reports to Curecode. I think 
we need a separate project for that. There could be hundreds of issues 
and they shouldn't be mixed with Core bugs.

Is that a GUI or core error ?  :)

that's a dialect error. Try to source stylize.

Do we really need a r3 curecode project?

But there is a graphics section under cc

Or a pessemist :)

Better to be prepared for a flood of reports. I suspect the GUI might 
be a bit popular.

Need to finish a project first and then we're beginning. Hopefully 
next week. With a place to report bugs, you can start a little earlier.

If you need more attributes than the standard gob! provides then 
just make the data attribute an object! and put them in there.
 Right, and that object is called a "face".

I was just reading about upcoming new Facebook facelift ... and following 
the discussion I found out, that one person suggests very cool Facebook 
client done in Silverlight. I needed to download SL beta 4. Then 
I tried that mighty app. Guy, I can tell you - we can do it in View 
anyday. Its not any faster, any better, and I would really like to 
see the ugly code behind the app. My long time suggestion to popularise 
View is to wrap known services - gmail, FB, etc. E.g. especially 
on my Winmobile, ther's a FB client done by MS, and you can't even 
read more than 1 reaction to your post. I imediatelly can imagine 
Winmobile client in R3 :-)


Here's the screenshot - http://xidys.com/pekr/facebook-silverlight.jpg

Graham, the first definition of "facet" is the one that applies here. 
The part of a gemstone that has facets is called the face. Facet 
means part of a face.

face - 2nd level gui object with gobs, like a scheme
facet - part of a face
faced - local variables for a widget instance

It's a perfectly valid english word, used correctly. And it's clearly 
related to "face", whereas "part" or "attribute" is not. "Part" of 
what?

It's not just jewel related, it's a general term for "part of a face". 
It's just used metaphorically for jewels, meaning part of the appearance.

I don't know about "faced" though - it's been a while since I looked 
at the GUI code, so I don't remrmber what it means.

locals is probably a better name than faced

The metaphor is widely used. And there is a lot of English that isn't 
generally used, because most people aren't specific enough in their 
language. Only linguists, literary types and tech people are specific 
enough in their language usage to need a large vocabulary. For instance, 
I had to study historical linguistics to get a specific enough vocablary.