• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 2701 end: 2800]

world-name: r3wp

Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public]
I would like to get back to Oldes' quesiton - is unloading extension/module/gui 
or other elements technically impossible?
Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?
Group: !REBOL3 GUI ... [web-public]
You're confusing GUI with graphical subsystem. In R2, face was used 
in graphical subsystem, R3 uses gob! instead. Face in R3GUI stores 
all GUI-related informations and cannot be compared with R2 face.
Studying GUI I have following psychological problem - I never know, 
what possible elements it might contain. The problem is evident, 
when you create style using stylize. Even Carl was aware of that, 
and e.g. for actors he created comments, so that user know, what 
argument it takes. Looking at various styles, I always wonder, if 
I can make any facet I want, or is there any MEGA FACE object, containing 
all possible fields? :-)
with prior gui, I could see 'draw-results, or something like that 
in the structure. Was it removed? What was it good for? :-)
R3 still hard crashes with the GUI :-( unreproducible ....
But generally yes, for forms, I expect easily setting up pairs of 
right alighned labels, and fields. That has to be ultra easy, along 
with the ability to set some margin, but that should be workable 
via the stylize.

Henrik - I think that if you add frameless alternatives, then it 
is not a big deal ... I just have problem with current aproach, where 
subpanels create too many lines in the GUI :-)
Tagging is neither facets nor options. They are information that 
usually relates to the GUI system to describe the state and capability 
of the style.
There are two concepts, which might be helpfull (maybe it is one 

1) having the same style in various sections of your GUI styled differently

2) having the option to style differently the same style in the same 
level (that can be done by options)
re "I thought that you might find a way of how to do it in terms 
of just one panel" - it is possible to do it in "just one group". 
Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts 
than R3-GUI (H/V)panels.
In R3 GUI, style names themselves act as classes, where in HTML you 
have a fixed set of tags that need to have classes. IDs are set-word!s, 
so there is no need to add any superfluous layer to identify specific 
Henrik, not quite.

using CSS you effectively "tag" your gui and then you can apply effects 
to multiple types of things which match a tag or pattern.
Maxim, this is necessary in HTML, because of the fixed naming of 
HTML tags. set-words in the R3 GUI do this.
I suggest that classes in the R3 GUI is not useful for the reason 
that it interferes with the "intelligence" layer, where we already 

1. tags to identify state and capability of a face, such as finding 
the default button in the window or whether the button is disabled.
2. name to identify a specific face

3. style name to identify the style and to create a distinct appearance
4. the ability to group faces by panels

5. have information about the ordering of faces stored in the face 

6. use specific policies on how to act on a particular face with 
particular tags
Henrik - you see? I just wanted to have a "button" inside of view, 
and by change of stylize parameter, to change some aspect of the 
button. But I might be mixing few things together. In your above 
example, my-button is a class. So your saying that in R3 GUI, classess 
are not usefull, is an incorrect statement, as we already do have 
classes? Or what you would call your 'my-button then?
So your saying that in R3 GUI, classess are not usefull, is an incorrect 
statement, as we already do have classes? Or what you would call 
your 'my-button then?

 - A style is not a class in the HTML sense, where you can apply a 
 particular class to any tag.
Cyphre - what will layout be good in next version? To preconstruct 
GUI, not displaying it?
Hi, here is an R3-GUI poll once again:

For the resizing purposes, all elements have MIN-SIZE and MAX-SIZE 
specifying the limits of resizing. It is easy to see, that, unless 
MIN-SIZE <= MAX-SIZE in both coordinates, the requirements are contradictory. 
(For example, if we set MIN-SIZE: 100x100 and MAX-SIZE: 50x50 for 
the same object.) Currently, the code does not trigger an error in 
such case (not having a built-in test for it), giving the priority 
to the MIN-SIZE.

The poll question:

What do you prefer to happen in case object MIN-SIZE and MAX-SIZE 
dimensions are contradictory? Do you think the current behaviour 
is acceptable, or do you want the code to always trigger an error, 
if conflicting requirements are given?
it shoudn't be an error.  popping errors in gui code is generally 
pretty evil if it can be prevented...  its better for the gui to 
look weird than the interpreter to jam for an unknown reason.   the 
possible layout screw-up will be incentive enough for the bug to 
be fixed.

a logging system could help us identify where the engine "thinks" 
there might be problems...

a debug switch which compiles warnings like this would be nice.
I hate gui errors .. I'd rather have a screwed up display
A small note:

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

In GUI language I have seen the GREYED "v" means BOTH "true" and 

Example: you want to filter in a database which customers are active, 
you set it to true,  which are inactive, you set it to false (nothing 
visible). You want both true and false the you have a third state: 
the grayed V.
I have problem accepting result of examples:

15, 23, 24, 25, 26, and I stop here, probably many others ...

The problem I see is,that I don''t want elements to jump during resizing 
the way it does. Please try form example 15. IMO if we don't support 
scaling, the text and its spacing should not change at all. I would 
expect panel being enlarged, but all it does is the panel moves down, 
and GUI creates space between the header text and the consecutive 

Also - look at example 26 - why the last line of boxes is shifted 
down the window from all the rest of the boxes?
Panel example #35 - I just wonder, how many ppl will feel lost the 
same way as I feel. The naming terms in regards to results are difficult 
for me to resolve. As for alignment, there is several way of how 
to name things:

halign, valing

left , right, center (vleft, vright, vcenter, hleft, hright, hcenter)

left, right, center, top, middle, bottom (or the corner alignment 
-  top-left, top-right, buttom-left, bottom-right - if those would 
be used, I would immediatelly understand it)

But - let's try to think about it a bit - we have some alignements 
in various GUI levels. If possible, let's stay consistent (e.g. it 
is enough that low-level text handling uses MS Word like terms, which 
don't relate to the rest of the gui)
I think the edge/frame/border usage is a little confusing. EDGE was 
a standard feature for every face in VID and it was fixed how it 
worked. In R3, an edge would be implemented on the DRAW level and 
could basically mean anything, including what it means in relation 
to the box model. This is why I'm still advocating a special FRAME 
style, which in *one* place, settles the meaning and the appearance.

Furthermore, a FRAME could be required for any type of face, be it 
a form with many fields, a compound of faces or groups of compounds 
of faces, which need to be surrounded by a pixel accurate frame, 
like in the example below, which I had trouble defining properly, 
when I experimented with skinning:

I had problems with it, because it had to be part of COMPOUND, and 
yet, certain COMPOUNDs would not have a frame and certain other panel 
types would also require the frame, but not be a compound. It is 
just much simpler to have it in a separate style.

I have ran the latest RE-GUI and the examples. I have see that when 
the CHECK is off the "v" is still visible but greyed.

GiuseppeC]] - you are not the only one who dislikes this. Count me 
What's the resistance? You just need to understand, that there might 
be some users, not understanding GUI internals imo. I put above comment 
on purpose here, explaining WHY exactly it behaves as it does. Just 
stating the something is correct without further explanation does 
not help to understand the case ..
What users poll are you talking about? I do remember some, and when 
I can't take any preference, I don't participate. OTOH I put many 
comments in here. In fact - R3 situation is so "devastated" from 
the community point of view, that there is very little ppl participating 
in actually anything R3 related. Even in time of Carl's GUI, I might 
be the only public tester, may 1-3 other guys I remember. Where's 
all 300 ppl registered here with testing and comments? How much of 
input you get from any other person?
What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 

What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:

tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]

Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)

My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 

1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?

2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors



It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?

My comment is just food for thought, not a claim to change anything.
Dunno where to chat about Jocko's demo, but as Henrik suggested to 
move here:

- some parts are sluggish

- for Rebolek - you can look at Demo/To-Do section - Jocko outlined 
some changes he made to some styles. His demo does not work with 
current RMA release if I am not wrong.

- we should generally start to think, about how to "unload" certain 
GUI parts from memory. By just clicking here or there I got from 
11MB to 38MB of memory usage. In some old GUI I used, it kept track 
of windows, and those were GC'ed when closed. In REBOL, if I am not 
mistaken, after the layout, faces objects are defined, and there 
is no automatic way of how to "undefine" them and free the memory. 
So my question is - will that be addressed, or is user responsible 
for the resource tracking? And is it even adressable?
No worry - even if you will be coding in RED, it will not have GUI, 
so :-)
One general question to GUI/gfx gurus. I know it is very preliminary, 
but - what about scaling? I mean - playing with my phone, I wonder, 
if it is facility of mobile OS, or particular app is receiving some 
zooming info, and acts accordingly? Are we ready for something like 
that? Because just recently, what we do is - resize. But we don't 
scale (fonts). It is just question of catching particular OS events, 
and create particular actors?
Old flyouts changed offset in loop, so if you switch panel's show-mode 
to 'fixed, you can make this effect very easily. You can also animate 
resizing this way, but GUI will be blocked because show is handled 
inside loop and not using timer event. But if you keep the loop short, 
user won't notice that the GUI is blocked.
Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.

I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.

Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :

It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        options: [
            drawing: [block!]
            init-size: [pair!]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ;-- JC
            on-draw: [face/facets/drawing]

Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 

That's all for the moment. When debugging the last demos, I may find 
other issues.
From R3 GUI sources:

tight: vtight [] ; for compatibility right now, will be removed

(in case you don't have access to source comments)
Everyone else loves it

 - I expect a little more objective statements than this. In fact, 
 I don't "love" MAX-SIZE at all. I just know (you have proven it), 
 that some relevant frameworks (like the OSX GUI) include it. I am 
 sure that is the reason, why Carl insists on it as well. So, if we 
 want Carl to "throw our changes to the R3-GUI to the basket", we 
 can remove the MAX-SIZE to achieve that goal.
Very short initial report to the new release:

- keyboard area text hilight problem still persists (when hiliting 
from the bottom up, only one line is hilited)

- drop-down shold be closeable by - clicking elsewhere in the gui, 
clicking arrow of drop-down, or hitting ESC
By the way, I probably should only be given 0.1 of a vote as I have 
hardly done any GUI programming with REBOL and certainly none with 
a suggestion for the next release of r3-gui : the doc style (the 
doc parser) interprets the first line of text as a title, which is 
not always appropriated. For instance, in a simple 

alert "this is an alert", the text is displayed as title. I think 
that this feature should be removed.
I was going to suggest a couple of alternatives but it is hard to 
find something that fits in with the VIEW/VID/GUI metaphors.
I'm not sure if the parent/child metaphor is appropriate in REBOL3 
are very useful words for precisely defining relative positions in 
a heirarchy.

They do not seem to sit well with the REBOL though as firstly they 
are comparative long (and many rebollers appear to worry about having 
to type one or two extra characters) and secondly they don't really 
fit in with the existing VIEW/VID/REBOL3 GUI metaphors (which are 
more facial - FACE, GOB etc.)
Please, check the http://www.rebol.net/wiki/R3_GUI_terminologyarticle. 
I hope, that is describes some of the terminological issues we are 
trying to solve.
if we wish to generalise, then [ panel 0 panel 90 ] so that in future 
we can go [ panel -45 panel +45 ] 
Can this GUI do this?
1) no clue. didn't read the gui terminology recently
The wording of the http://www.rebol.net/wiki/R3_GUI_terminologyarticle 
corrected and enhanced.
Maybe we're just tired of user polls, or we don't have the time to 
dig into this. If you don't have a clear view of what a good GUI 
should be, and therefore need polls, then maybe use some time to 
get a clear view. Only suggestions. :-)

I looked into it quickly, and I would at this point go for just have 
panel, letting vertical be a layout-mode option. Reason: K.I.S.S. 
(and vertical is an option anyway). And if you support user-defined 
styles (I'm not sure, you do, as I'm not very much into R3 GUI), 
then programmers can just make their own vpanels, if they need it. 
If I, as new to some GUI, can get it up and running in a very short 
time, because it's so simple, that's a huge benefit.
If you don't have a clear view of what a good GUI should be, and 
therefore need polls, then maybe use some time to get a clear view
 - interesting point, should make a note
In the case of the above poll, all alternatives have their advantages, 
as is already mentioned in the article. That is why a "good GUI" 
can use any of the alternatives. A "preferable GUI" should use the 
one the majority prefers.
I guess, it's extremely hard to create a really good and preferable 
GUI. I'm struggling with Cocoa and Interface Builder on Mac OS X 
atm., and I haven't seen any glimpse of a 'perfect' GUI in that yet. 
If I was to design a GUI, I would go for simpleness, and still make 
sure, advanced users can make the advanced things.
Suggestion: If you have user-defined styles, then why not just go 
with a very basic set of styles to begin with, like only panel, group, 
etc. And then you could make an advanced version of the GUI (by including 
some script with styles), where you give users vpanel, vgroup, etc.
Result will be, new users don't read very much documentation and 
can start using the GUI very quickly. If you wanna do more advanced 
things, read the advanced docs, include the extra script and there 
you go.
A R2 GUI document, I've used a lot over the years, is:

About everything is there in a small space. It's a very good document 
to get you going, almost perfect. Maybe just a little too long still.
I find that if something should be decided, you should look at how 
easy it is to change the code based on that decision. The easier 
the code is to change, the later you can make the decision. This 
gives people a chance to test the GUI with that particular decision. 
In this case, we are working purely with style names, as far as I 
can see, which is possible to change in a few seconds, if we don't 
like them.
Are there much R3 GUI code, that people actually use?
Ladislav - in your GUI terminology doc, panel/vpanel section, isn't 
there a typo in the source code? Imo it should be panel [button button], 
not hpanel [button button]
We are going to re-factor the complete ACTOR & REACTOR stuff in R3-GUI. 
It will be streamlined, much simpler and more common in that it follows 
"best practices" from other GUI libs. The side effect is, that this 
is a bigger re-refactoring step and will take some time. Until done, 
we are not going to make a new release.
As status of RMA's GUI is more of a private effort targetting business 
level apps, I can imagine kind of simplification, which makes it 
"dumb, incappable and more rigid than possible", because it just 
fitst your limited business apps needs :-)
if you can't, then the GUI will be entirely useless. you couldn't 
even start it.
One of the attractions of #1 is that it makes it easy to implement 
"default handlers" at some point higher up the hierarchy. For example 
based upon an  "esc pressed event" (if one were to exist.) and you 
had designed a panel with four buttons. If you wanted to close the 
panel when the user pressed esc, you would simply have a single "handler" 
for the panel which would receive the event.

I'm sure that this isn't  the best example and apologise in advance 
for my ignorance of REBOL3-GUI and its common terms.
Any news from RMA guys? Not trying to push for anything, just curious 
about the progress of the GUI implementation. Acutally I do remember 
you stating you are taking longer time before there is next relase. 
So how things go?
Quite good. We did some major re-factoring and are currently getting 
automatic GUI testing done. We need this for several reasons:
1. Automatic style lib testing
2. Applicaiton testing
A post to keep you informed about what the ELICA LOGO can do relative 
to 3D graphics, animation an GUI (under windows only) - all their 
libraries are open source and I thought you would like to know about 
- see the link in the OPEN GL group. Hope it can be useful in some 
way or another. Regards, Gerard
The current overview of all styles:


Some more images here:


A bit of status:

- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts
I am referring to: http://rebol.hmkdesign.dk/files/r3/gui/255.png

- hmm, no horizontal scrolling?
Simple demo of automated testing:

We are currently discussion an option how to write GUI dialects. 
The thing is how to access face stuff. At the moment you write it 
like this: get-face/field my-table [cell 2x3]

Whereas I like path notation more: my-table/cell/2x3

Using path notaion is not possible but we could enhance the dialect 
in a way that: "get-face my-table/cell/2x3" would be converted internally 
to: get-face/field my-table [cell 2x3]

So, what do you think? I'm not sure if supporting the path notationis 
worth the effort.
Tag field style:

Taken from RMAsset Twitter: "We plan to release a new R3-GUI version 
next Friday." Any significant changes about tobe expected, in comparison 
to latest release?
ok, thanks ... Ithought that R3 GUI is suited for that task, but 
that would be probably a preliminary assumption :-)
That time is better invested in allowing people to work on specific 
things, like the automated testing system for the R3 GUI, rather 
than specialize ourselves into a corner this early.
With our R3-GUI test-system available now, we could really need some 
help in creating test-cases. The more the better. We want to build-up 
a huge test-suite for GUI tests that we run on "every commit" to 
keep quality high and identify breaking changes.
The more help to build test-cases and submit them to us, the faster 
we will be in pushing R3-GUI forward.
I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3

Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...
Cyphre - is there any chance Carl is going to be available to do 
some low-level fixes? It kind of crashes very often, but of course, 
with one specific use-case, so "normal GUI usage" (whatever that 
means) could be without any problems ...
great release ;-) thank you. perhaps ask carl to do somethink for 
gui on linux
As for the possible "look & feel" of the GUI, I personally like HTC 
Sense, and Linux Mint - combination of light greay and green. IIRC 
Ashley created some more lightweight look for his GUI too later in 
the process ...



Take it just as a note :-)
So, I see no one is really interested in this R3 GUI stuff... I'm 
wondering a bit but anyway... I think doing public releases might 
not be worth the effort.
Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?
Robert: you are wrong.  As Pekr said many of us are waiting and busy 
with something else. I downloaded all the RMA R3 stuff, tested all 
GUI examples (found some crash problems btw) I really would like 
to help/write a tree style, but I'm not a good Rebol coder I'm afraid.
So please keep up the work.
Robert -- an R3 GUI just isn't one of my priorities just now.

While  there is no likely target date for a beta release of R3, all 
my REBOL development is on R2.

I was happy to help debug R3 alphas while that project had some momentum, 
and I may be again in the future, But right now, I just do not have 
the time for what I have to consider to be speculative projects.

I hope you do get the help and feedback you need.
I will be more actively interested when I start having to write code 
that requires any GUI at all, but what I'm working on right now doesn't 
even need a web interface. All batch and server stuff, and almost 
all the REBOL stuff is R3. This can't last forever, so I will eventually 
need a GUI. I am working on ODBC though.
Well, that contradicts a bit expectation, that RMA's GUI is RT's 
officially endorsed GUI to be bundled with R3. OTOH there are no 
official R3 releases anyway, so ....
I understand that you are focusing resources as much as possible, 
otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept 
changes during last year. Anyone eventually willing to give it a 
try once time permits will think twice, as recent public release 
could be pretty much outdated in few weeks, API wise, etc. There 
should imo be a way, that upon some request or bunch of requests, 
public release is done e.g once in few months?
That are not the same excuses. For core, the excuses are, that Carl 
is not developing. For R3 GUI, the excuses are that we *are* developing.
hmm, that makes R3 GUI a private, mostly a closed effort. The only 
question which remains now is - once R3 development is re-established, 
is R3 GUI becoming part of official distribution, or not? What's 
Carl's take on that? :-)
That would depend if Carl approves it, and AFAIK he has not looked 
at any of the changes yet. However, it won't affect the development 
of the R3 GUI, whether he approves it or not. It will still be made.
ah, so it might be just a separate package,like RebGUI is to VID 
... yes, that's possible too ... we just did not want to have many 
GUIs available. But R3 GUI is in limbo anyway, so ....
So the GUI we can see in screenshots is modified RebGUI? Looks decent 
enough. Similar skin would be nice tohave for R3 too ....
So the GUI we can see in screenshots is modified RebGUI?
 - yes
jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.
Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?
Group: !REBOL3 Host Kit ... [web-public]
I'll get to that when I start porting View to the Syllable GUI, but 
that project is still a bit in the future
If RM want more people to join the GUI development, they should sync 
the host-kit with Carl.
advanced WRT to the graphics & GUI stuff.
Rebol strings are stored either as ANSI (one byte) or wide char (double 
byte). Of course the rich-text module is currently doing the conversion 
for every rendered ANSI string in realtime. Any sophisticated rich-text 
caching is not yet implemented. (note: this has nothing to do with 
font glyph cache which works well) But even though the cache of large 
text block is missing the performance is still very usable for normal 
GUI cases so the priority to spend time on the line-cache is not 
too high at the moment.
Group: !REBOL3 Proposals ... For discussion of feature proposals [web-public]
The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.
but not only GLASS, we have the same wory in any GUI engine
several tens of megabytes to just display a simple GUI pisses me 
re DEDUPLICATE ... it's not just GUI code that would benefit, DB 
code often needs to apply this on the result set. "buffer: unique 
buffer" is a common idiom, which can be problematic with very large 
2701 / 286712345...252627[28] 29