• 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: 2501 end: 2600]

world-name: r3wp

Group: !REBOL3 GUI ... [web-public]
oldes Rebol GUI is just an interface on top of  your local system 
windows management  API.
Are we talking about same GUI? What I know Rebol gui does not use 
any native api and there is nobody I know working on it.
so yes the goal seeked is for the rebol programer to have a transparent 
and portable API in rebol to make graphical user interface. But on 
the ground level you need to adapt the C code to your OS window management 
solution... With some specific tweaks for example on linux you are 
not obligated to have X11 started so you linux rebol/view -hostkif 
R3/GUI- have to detect if the X11 server is run and if it will be 
able to display things or warn you it can't
that's window... that's not eaqul to gui for me.. and I really don't 
understand what's the point.
Oldes that's because you are not aware that all your R3/GUI calls 
need to be displayed on your screen  and that rebol doesn't handle 
that part ? and that the same for the mouse / keyboard events...
and since i'm considere as a pain in the ass and you all try your 
best to not have this discussion with me  or with the others in the 
community then you go to what Carl did without any second thoughts 
in the end we will end with a strong win32 API based R3/GUI and no 
linux or macOS X ports. That' s the the projection I can make base 
on the actual work.
GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.
oldes glut is compact, it's C based, it's portable on linux, windows, 
macosx only 117Ko and it opens a big gate to opengl since that's 
it's main purpose... Agg could be adapted at some point to use hardware 
accelerations proposed by OpenGL API at some point or at least we 
can investigate that part... Glut is old so this means it's super 
documented, and glut goal fits what r3/GUI basic goals are manegment 
of windows and management of user's inputs
that's the kind of port quality we are talking about ok but then 
R3/GUI will be no different as R2/VID
GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.
anyway for text processing who cares even having a GUI library ...
OLdes henrik and any other that wants me to make my own R3/GUI ok 
but since your are the gurus then I'm pending on your teaching and 
leading  for me to achieve that goal :)
cyphre yeah you want pathetic brainless followers that appauds any 
of your moves.... Sorry that's not my style.. The thing is the people 
telling me to do my own branch of R3/GUI  for free obviously to there 
benefits don't know how to do such a project on their own to start 
with so there is obviously nothing to be expecting coming from them.
patience ? since when do we know that  R3/GUI is externalised to 
R3hostkit ?  Since when do we know carl is having terrific problem 
on this matter ?
I tryed to have this discussion in the early stage of R3/GUI project 
I was pushed aside I tryed to have it again some month after  with 
same result and now again some month after nothing have changed and 
you tell me to be patient ?
Repeating from above:

We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...
will that documentation be anought to start another branch R3/GUI 
? I think that's not the topic in fact. That's documentation to allow 
us to test your product and be productive beta testers.
once angain those documents are just here to serves you own interest 
not our... My interrest is to have a R3/GUI that is based on a community 
real effort and organisation, that produce documentation and that 
tends to involve everyone and not limiting them to the role of beta 
testers.  My interest is having this library with one to one link 
everywhere. My interest is to have this module/library  discussed 
all aloing and with futur granted ... We don't know if RMA will produce 
something affortable we don't know if after this first shot what 
will be the level of evolution we can expect from it ... Do we will 
need to pass to bounties to get new things added to it once the main 
release is done ? how will be integrated and rewarded external contributions 
to that project ? why only the 5 of RMA should get money out of this 

SCRUM tool prototype GUI example. We are exploring how to organize 
the GUI, as the R3 GUI can be used to prototype things now. The next 
step here is to get it integrated with the database reactors prototype 
written earlier. If that is done correctly, we should be able to 
switch from a prototype file database to a different database backend 
(SQL based) without touching any GUI code.
We should start talking look & feel at some point too, as it really 
looks completly strange :-) Cheap gradients with Aqua like old Mac 
look mixed with 70ties Unix grey aproach :-). How can anyone create 
anything like that nowadays? This is really strange, as I remember 
Gabriele's effect-lab, Cyphre's styles pack, and also Henrik's first 
UI attempts, and those looked much better ...

I need to know, if it will be adressed, as I am scared to touch the 
gui, as I fear it will do really something bad to me :-)
btw what happened to the old R3 V2 gui from carl? could this be used 
as a starting point fpr another GUI?
Tom, Carl's GUI was inadequate in many ways. The one we are building 
now is directly based on it, but replaces parts of it, like the resizing 
Pekr, what you think is ugly and cheap design, is actualy THE FUTURE 
of UI design. Every GUI will look like this in 2-3 years, I wonder 
you don't see it. At least you understand this is the definite and 
final design of R3GUI.
Rebolek - my dog randomly drawing would come up with better aesthetics 
probably :-) One should have pleasure to play with the stuff in the 
process, while I have really a hard time looking at any single screenshot 
of new GUI. What I don't understand is, why it changed from the former 
look, if draw code for such style was already available?
I will not participate to any bug tracker, bug correction, or testings 
regarding R3/GUI until we don't have a full detailled schematic of 
R3-host-kit, while we don't know where we are going with this project, 
and while we don't know if a better path can be found to avoid this 
project to fall in porting maze.
I have to support Petr's dog here. I fully understand why looks are 
not a priority for development, but I also know that if we proudly 
present the GUI functionality to the world with the current skin, 
almost everyone who sees that will confirm in his mind that REBOL 
is a thing of the past and will never touch it again
Shadwolf, if you want a REBOL GUI that can just be recompiled on 
all platforms based on OpenGL or QT or GTK, the current host kit 
fully supports that. You can just build such an interface on it
I apreciate the work put onto R3GUI. I am just a spectator, I am 
not involved into the development. So I whish to say thank you to 
all the people building R3GUI.

From time to time the community get nervous about lack of development 
or inadequate results. Please note that they are building the foundations 
for further work. One time in the future the GUI will have the look 
similar to MacOS or GUI found on mobile device. Until then an old 
fashioned GUI is better than nothing.

Please consider all the hard work put from unpaid people on this 
I like that the UI look isn't inherent in the GUI. Skinning was a 
value from the beginning.
I have only a couple of request: please consider now the modification 
to the event system to support multitouch devices and whatever is 
needed for smooth GUI animation. It is important for further porting 
on other platform.

Also, keep in mind that good documentation is essential to let people 
use your work.
I think Pekr speaks of the docs included in the RMA's gui zip. The 
format is apparently done to be converted by makedoc2.r
Shadwolf - this is not the right group to discuss advocacy/strategy 
kind of things. But here's my take:

- RMA is a commercial entity, and Robert made it clear enough - they 
develop GUI to the point, when it will be usefull for their business 
apps. The chances are, that if it is good for them, it will also 
be good for others

- Robert is a good guy! He pays several top community guys, and - 
he gives result of such work - FOR FREE!

- RMA guys are VERY open, to listen to other's opinion, it is just 
they will accept only REALISTIC proposals - trying to convince them 
to change to differet underlying toolkit CAN'T work at this point. 
Even if such a toolkit would be good time solution, there are no 
free resources to make such a big change

- RT (Carl), plus the community, should be gratefull, to have at 
least RMA's GUI, if there is not other gui in the spot, and RT itself 
is not active in that regard.

- If I should name at least something what I am not considering so 
optimal, then it is a bit of a closed nature of development. I mean 
- I might wrongly understand initial impression of a SCRUM model. 
I missed the big picture, plus particular reports ... but - ANYTIME 
I was not lazy to ask, my questions were answered. Anyone but me 
can do just the same - ask. This is called - communication :-)

So much for RMA and their relation to development of R3 GUI ....
Ok, except that the power of REBOL was that it can run under 40 different 
OS !

Nowadays, it runs good for R2/View under Windows and MacOS... Linux 
lots of problems because there's so many version of Linux...

And for R3/GUI we have Windows version... and when Windows 8 will 
be released... not sure it will work.

Community has falling down and it is hard with no open source to 
attrack new developpers... I know host-kit is hybrid open source 

Real question in 2011 is : port language on JVM because every computer 
and device (except iPhone) has a JVM in order to reach the mass market.

Make it popular and then we can found money, people to work on small 
VM that make the power of Power.
Used MDP to generate docs. Not optimal, but at least something. What 
I did was:

- replaced =image-code by =image
- shortened path, as images are just in the same dir as doc

- gui-panel-sizing-3.PNG should be renamed to gui-panels-sizing-3.PNG
- gui-panels-visibility.PNG is missing
Pekr native is a pain that's all ... it took already 5 years to do 
rebol VM version 3 on windows 32 and it's not over and according 
to the source code of r3-host-kit there is no GUI part in linux or 
macOS X.. we don't know either if more than the 3 main os will be 
supported and in what extense. Doing a change on 1 VM  means finding 
a way to do it on all other VM that's why if i remember well along 
the years R2 was supported on lesser and lesser OS and that's why 
too the rebol VM source code grow to a point that it was impossible 
for Carl to maintain it .That was the main justification for the 
retrofiting of Rebol VM  in the rebol 3  project... mean while all 
the  industry changed can you seriously say that  java vm is the 
same now that it was 5 years ago same goes for mono.
try this:

stylize [red-button: button [facets: [area-color: red]]]
view [
	button options [area-color: green]

I think this wirks just fine no?
The faced block is similar to facets block, but makes them local 
to each instance of the face. Now, they can be modified without effecting 
any other faces that are of the same circle style.
 It is taken from: http://www.rebol.com/r3/docs/gui/styles.html
OK, I will try new version, and see how it goes. I would welcome 
an example on 'intern, maybe I will find it in sources. Starting 
to warm-up to new gui :-)
I am still not sure I am comfort with group having different semantics 
to panel :-( .... trying to do some tests with Carl's demo, and it 
is going to be pain-in-the a..., to insert returns in there. From 
the very beginning of the R3 GUI projects my opinion was, that group 
should be just de-stylised panel (no visual borders), but identical 
in behaviour ...

I hope I will change my mind later in the proces ....
btw Pekr, from an API designer's standpoint, these types of questions 
are all very good  IMHO.  they force us to reflect on decisions and, 
often, trying to do so will either confirm them or with discussion 
might give new ideas.   I'm not part of this gui team, but I'd really 
like if someone asked pointy questions like this on my stuff.
those come from concrete effort to make Carl's demo translated to 
the new GUI engine  :-) First and second screen is displayed, but 
make-panel just differs, and options argument does not exist anymore, 
it also has reverse order of arguments, and does not accept style, 
but face instead, and so on ...
hmm, I don't know why, but I don't like those long name functions 
as set-panel-content. I already disliked it in Rugby times. Too much 
function variants. Sometimes I think, if REBOL does not have something 
wrong. I thought that set-panel 'param 'value or set-panel/refinement 
could be a better way, but maybe it is not. I miss some level of 
better functionality encapsulation from time to time. We can't use 
set-panel, as it serves for setting of its content ... I probably 
prefer old-school object panel.method aproach ... that is just a 
philosophical note, not a complaint to R3 GUI :-)
E.g. one of the examples in the gui-panels.txt
btw - I expect that you guys surely know what you do, and so far 
my gui understanding is still minimal :-) But anyway - was there 
really a need to make make-panel internal? Except for the options 
block, I found it nice, that you can easily create panel from the 
stored layout block, just by one function ....
Then I found out, that their max size was set to 900 pixels. I asked 
Carl - why? And he told me, that fields should not be long, or it 
does not look nice anyway.

 - This is the main problem I have with VID and the "official" GUI 
 stuff. If I want it that way, I want it. I don't need a framework 
 that makes my life hard. There are zillions of things people want, 
 and others don't like. For commercial apps, we need to deliver what 
 the customer wants, not what we think is best.
And, to do this, all parts of the GUI must be accessible and able 
to describe. Hence, MIN-SIZE & MAX-SIZE make sense on a face level. 
If I need to specify it, at least I can.
Our GUI will not be a toy. It's not for people just starting to play 
around. R3 needs a full blown commercial & enterprise app enabled 
GUI framework. Otherwise it will stay a toy no one cares about.
Content isn't bad, but I think local is more descriptive.


The faced block is similar to facets block, but makes them local 
to each instance of the face. Now, they can be modified without effecting 
any other faces that are of the same circle style.
I think that in the new release FACED is really gone. Nicolas points 
to RT's docs, which imo refer to Carl's GUI, not RMA's one.
OK, I will adapt ... the intention is to make demo working on RMA's 
GUI. We will see, how it turns out down the road ... I am slow, because 
I still have little knowledge of GUI itself, pluse I am really not 
a programmer :-)
Should text style work?

text [bold "Toggle button..."] gives me:

Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none

** User error: {TO-TEXT - syntax error at: [bold "Toggle button..."] 
Got to go - but - is there anything like vpanl alignment? I got first 
form of demo kind of working (buttons), but the content is aligned 
to the bottom. Also - pressing buttons does not work so far either:

** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller
Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		check "Checkbox attached to above toggle" attach 't1


child: make-face 'vpanel []
set-panel-content child lay
view child
hmm, it really seems to be in r3-gui-src.zip ...
ok, then I have maybe messed r3-gui.r3 .... will unpack the latest 
one ...
I use the latest r3-gui.r3
(since I was unable to reproduce the problem, I bet it is exactly 
because I never ran the LOAD-GUI twice)
It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
Pekr, any news about porting the Carl's gui demo ?
One thing is clear - it will not be complete port, e.g. fly-in/out 
effects are not supported when changing the panel content (switch-panel 
function is not adapted yet). Somy styles are also not adapted to 
the new GUI, and some are not adapted to the resizing model. I would 
welcome if RMA would do that basic work. E.g. even something like 
view [doc "text"] is guggy, and it displays the content twice, etc.
Cyphre - simply put - in a demo I am porting, I am not able to get 
the subpanel to work - it displays, but  don't perform actions. E.g. 
single button press causes:

** GUI ERROR: Cannot parse the GUI dialect at: panel 240.100.80 title 
Alert grou
p doc Button pressed! scroller
Or I have something wrong in the demo code, not yet fully adapted:

view-sub-panel: funct [
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [

  pan: make-face 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
						request "Note:" "Pick a test first."
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]
We can't easily make 50x50 button for e.g.? With Carl's GUI, it was 
really easy - button "50x50" 50x50, but with new gui, even if initial 
size is valid parameter of an option block, the requested size is 
not prserved, as can be seen by simple: view [button 50x50 "test"]

I hope we are not back to nonsense of being more clever than what 
user wants, limiting the size of a button?
no. having an engine which provides great GUI defaults is essential, 
but not at the cost of being able to tweak a widget .

skins/themes/stylesheets provide usefull defaults,  but having access 
to overide any of this is absolutely necessary.
sorry, but having built "large apps" and for clients, this freedom 
is very necessary.  

if you don't use it that will make the gui generally better, but 
there is always a time when its required and it has to be possible.

what VID lacked had nothing to do with styles and looks.  it was 
the fact that everything under it was insufficient at best... layout 
sucks, event system sucks, dynamicity sucks, no way to switch stylesheets 
on the fly, no locale, etc.
Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy. 
If I want 50x50 button, don't even dare to dictate me, that I can't 
easily have it. If I can't, I almost refuse to use such a system 
This is rudiculous - so you have init-size as an option, yet it is 
ignored,or totally twisted, in that regard, that only X axis gets 
adjusted. That simply does NOT work as expected, and if you guys 
refuse to understand, that the freedom of expression is what ppl 
are interested in, then you are building completly different GUI. 
It is supposed to be easily used.
Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning. Carl's GUI used skinning, and was able 
to provide such buttons. That is just stupid limitation imo, and 
should be removed ....
You have min-size and max-size still, right? To support resizing, 
you need to support sizing. But that doesn't mean the syntax is the 
same as in R2's VID or Carl's GUI.
The current design is supposed to allow non-GUI-designer programmers 
to specify layouts. Even if you are both the layout programmer and 
the style designer, the work is supposed to be separated. For that 
matter, a proper layout dialect for the types of apps that the R3 
GUI is made for (not games) should be portable to other device form 
factors, accessible, etc. So if you need to be a theme designer, 
do it in the theme section of the app, not the layout. And if you 
need to be picky about the styles, do it in the style section of 
the app, not the layout.
BrianH: the strange thing is, that different color is actually supported. 
It was not with Gab's GUI IIRC, that was even more strict. I can 
imagine the trouble with mateiral system, when you allow simple color 
override. But - how is button's size influencing  or limiting the 
skin system? It has nothing in common imo with Carl's or other's 
version imo, it is just one developer applying his idea. How does 
new system differ to Car's version in that regard? Carl's version 
was supposed to use skinning too, so?
When I expressed my opinion on Gab's GUI to Carl, I told him, that 
I miss some aspects from easy of use of VID. I can understand, that 
when things get more complex, you have to put some limitations here 
or there. But - it stopped to be a fun. I need a system, which I 
LIKE to use, which is NOT BORING to use. If I want to use boring 
business GUI, I can go to Delphi with its boring the same buttons, 
and I even believe, that in the end it is Delhi, which allows me 
to shape the button WHATEVER size I want.
The current design is supposed to allow non-GUI-designer programmers 
to specify layout

 - no, it is apparently not. Layout user wants 50x50 button, and can't 
 have it.
The worst thing we can do is to let the option there, while not acting 
upon the override. So - if we REALLY want button's size to be fixed, 
the option really has to be removed, and it has to fail on GUI parse 
From Max: "I don't want to post stuff from other engines here since 
its not a comparison game, but I've used many APIs from prbably 20 
different dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on."

And I say - Amen. Set it into stone, and you might wonder in the 
end, why you have no following. It is exactly the same reason most 
ppl are not able to understand, that no matter how logical it is 
to have the skin done as a last, R3 GUI did not get any following, 
because of the first look experience simply get's users not interested 
at all. And it was said here not jus by me. You can protest, but 
that is all you can do about it.
Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy.

Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning

An exact failure in understanding why face hacking is not welcome. 
Gab's GUI was not easy due to a number of layers needed to describe 
the look and feel separately, as well as requiring you to handle 
GOBs manually. But it supported applying proper meaning of styles, 
because Gabriele had the same goal as me. Carls does too and RM Asset's 
does this even more. We just have to take advantage of it.

Have you never had to fix someone's MS Word document, so that TOC 
generation, links, indexes, headlines, etc. could be understood by 
Word, because they had resorted to manipulating the words directly 
with colors and style, instead of using Word's style system? This 
is exactly the same problem. You will be teaching beginners that 
their layouts won't scale properly for exactly the same reasons. 
Many people therefore never really learn to create correctly formatted 
Word documents.
that's rather easy, but not easy enough. Still a different concept. 
You guys act like button is a text, and it is not :-) If I will have 
whole screen of the same buttons, I might use stylize, e.g. for the 
calculator widget, as an example, becuase constantly repeat button 
30x30 is not convenient for me. But it still does not mean, that 
ocassionally wanting to have button a bit differently sized does 
a damage. Do you think users are crazy and will make each button 
differently sized, just because they can? :-) (Well, as for MS Word 
files, some users are able to create completly twisted texts, bu 
still - that is a text, difficult to restyle ... while we are talking 
GUI here.
Now if I would think about comparing R3 GUI to html/css, then I am 
not able to compare it in my head, but doesn't inline CSS allow to 
override class setting?
Also - one question to the text style - in Carl's GUI (at least that 
is my undersanding from the demo) it accepted the block of rich-text 
dialect? That is not so with R3 GUI, probably an intention?
Henrik - there's no why imo yet :-) From my POV it is very preliminary, 
and I would orientiate myself to:

- adapting existing styles to new R3 GUI engine

- adding styles most commercial guis will need - table, tree, tabs

- be sure all styles behave in a platform compatible way (especially 
- reskinning/respacing the elements

- add support for ctrl-tab at low level to switch between the tabs
- fix all hard R3 crashes


- add support for accelerator keys, but visually, and in the code 
(requires rich-text, most probably autogenerated, to underline the 
letter, but it could be done a different way to - e.g. displaying 
boxes with accelerator keys upon the styles and Alt key press)

- improve the text quality, that is NOT ACCEPTABLE for the 21st century!

even later:

- add some funky styles as Doc to make documentations, wikis, etc. 
- HW acceleration support where possible.
Does a style have to have a max-size? I am worried about scaling 
to large screens. I remember that was a weakness of Carl's GUI. I 
know you guys changed the resizing algorithm, but I didn't catch 
what the new algorithm was.
I got that (was typing while you posted that). Second question: good, 
I didn't like that about Carl's GUI.
Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...
Kaj, well, Pekr took up the challenge to rebuild the GUI demo (to 
great effect as we can see), so I don't think it hurts to simply 
ask if there is interest in the community to perform certain tasks.
http://issue.cc/r3/1837<- maybe you should add the GUI project to 
Been away for a while. As the GUI documentation been produced ?
when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.

the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 

the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.
it may have scrolled out of the way, but there is an R3 GUI project 
in Curecode now.
Not that I understand anything about GUI implementation, but font 
rendering sounds like a mere technicality for me.
So you are referring to what happens when the faces are first rendered 
or when a user manipulates the GUI manually or both?
I personally don't like any automatic sizing... when I design a gui, 
I know exactly how I want the components large with pixel precision.
%trunk/r3-gui/source/panel-make.r3 and %panel-sizing.r3 committed. 

- SPACING initialization moved to the INIT-PANEL function
I still miss simple style to group things. I always wanted a panel, 
with border, gradient, etc., but then also exactly the same style, 
but with zero visuals ...

IIRC, in Carl's GUI, it was panel vs group - except the fact, that 
it group used opposite coordinate system - very unwise btw

In RMA's GUI, if I am not mistaken, group is internally completly 
different - it is here for those users, used to VID2 - you have to 
use RETURN keyword, it does not align in grid cells, etc.

So - how do I easily define inline style, which removes panel visuals? 
I don't want to create new style for such a simple and usefull thing. 
And I start to think, that 'group style is here just to confuse users 
Pekr: looks, that you will get more examples from Cyphre, who promised 
to pack some and make them available. So, I am afraid, that at the 
time being, you only have the examples from the gui-panels.html text 
I haven't kept up .. how does the GUI event model work ... is it 
comparable to DOM 2 event handling?
is make event! attached to a particular GUI object?
graham - the gui has many nice features/handlers. There are things 
like do-face, do-style, not sure if cause-action is there (IIRC it 
was part of Gab's GUI)
I am looking for the GUI for massess, not for academic stuff ...
2501 / 286712345...2425[26] 272829