AltME groups: search

Roadmap: Looks much harder to put together than I thought, due to 
varying stability/completeness issues with some basic styles. Will 
get back to this in a few weeks. In the meantime, releases of the 
GUI source will continue as normal. Cranking down the volume again....

There are many missing parts and a lot of bugfixes and changes that 
I know very little about, since I don't work with the lower level 
stuff. Some of the styles are already begun internally and it's possibly 
not a good idea to include them on the roadmap as community projects.

Also with the SCRUM tool, it probably needs to be finished, before 
we can tell what else is missing and that will not be a community 
project.


Each part mentioned above really needs to be done, but it was a lot 
less clear to me what exactly is ready in the GUI to do those things 
until some analysis today.

is not it possible to keep the compatibility with the Carl's demo 
and gui, which achieved a rather good level of usability up to A94, 
and which were rather well documented ? From this time, where alternative 
gui's were launched, we have nothing, apart from low level graphics 
programming, with almost no documentation.

Shadwolf said: "...so your idea of a working rebol community is a 
rebol community with 10 R3/GUI because 10 of us has different ideas 
on the topic."

I must say I have no problem having 10 or more R3-guis... it's always 
better than having none. Of course it would be nice to have at least 
the core shared, but you will not have it if you even don't try to 
propose something.

Regarding roadmap, I suppose a comprehensive graph style does not 
need much else than what is available now, as it would mostly rely 
on DRAW.

I think that talking a graph style, if we don't have tabs, tree, 
grid, is a bit preliminary. We need imo basic styleset, usefull to 
work with general DB apps, then we need more modern skin, and only 
then we need additional styles. We still can't see even concepts 
as accelerator keys being displayed, etc. :-)

But having a roadmap/plan, to answer questions as mine above, about 
what features are planned at all, would be usefull ...

The idea for the roadmap was to remove the need for RM Asset to do 
these styles ourselves later, when we are busy writing R3 end user 
apps, otherwise it could take a good 1-2 years before they would 
be publicized. The roadmap would be shaped around which styles are 
needed and which basic features need still to be implemented in the 
GUI.

That is understandable, for the styles ... but what about missing 
features? Will we add them, as needed? I mean e.g. - there was a 
discussion about the hilite/glow effect. One group of ppl wanted 
to have central abstracted behaviour, other ppl were talking about 
the per-style implementation, while there is third possible aproach 
- the mixture of both - central solution with possibe per-style override. 
Such things you need to account for, when writing your style, depending 
upon the decision about how it will be solved architecture-wise?

Pekr, I can't be sure at this time, because currently the styles 
are worked on via immediate need for fixes for things like the SCRUM 
tool, which is partially why I couldn't complete the roadmap. It's 
probably fair to say that the styles currently present in the style 
browser will be completed by RM Asset, but that may change.


What I imagine is that some of these styles that I mentioned will 
be comprehensive, long running separate, autonomous projects. A style 
like graph will need a ton of features, possibly separated into substyles 
and it would hopefully not depend on anything, but low-level features 
in the GUI system. Someone like Maxim could do this as he knows how 
to do high performance graphics. A windowing system can also be run 
as a separate project. Each project could be immediately stored on 
github.


RM Asset can do everything ourselves, but in the end, this will just 
take much, much longer, perhaps an additional year, which affects 
everyone interested in the GUI.

We follow a very simple strategy: We develop what we need, step-by-step 
and immediatly use it. So, we are not going to develop anything that 
we might need later at the moment. And, we are not first developing 
all styles, add a ton of features and than do our apps. We develop 
the styles just to the point where we can use them and than stop 
untill we need more.

In the beginning the chances are high, that the general & common 
styles that everyone needs are done because we need them too. As 
time passes, we will have a stable set of styles, that will cover 
90% of every app we will do. The remaining 10% well be done on-demand, 
project by project.

And, I don't see a problem if we have 2-3 different implementaitons 
of the same style. First, the code can be merged, we all learn more 
which patterns are good for style development and the whole GUI will 
be much better challanged from different POVs.

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 
to:
-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?...

Oldes  thank you for quoting me outside it's contexte to serve your 
purpose that quote is  a reply to Kaj proposition to do my own R3-GUI.

this quote implies any comunity work have to be based on a first 
step which seek the compromised best solution... which fundamental 
step wasn't done with the R3/GUI since their purpose is not to manage 
a  compromised vision of  R3/GUI edicted by the community but it's 
just to implement on top of the design edicted by Carl. In the actual 
design the least I can says is that you will need at least to do 
the work three time to support Win32API , X11 API and Quartz API.. 
+  any other windowed api. Knowing you are only 5 guys in RMA is 
it stupid to notice that and from this try to get the better solution 
the one that will give you best chance of success ?

the point here is the dialect edicted by carl can be adapted to any 
other library so why not considere taking a library already ported 
to the 3 main OS. Wich we would have the full sourcing and the would 
even in a shrinked version of it to save us the pain to do X times 
the work X being the number of  OS we want the R3/GUI on ...  and 
this  will too avoid us compatibility issues...

do for a R3/GUI we need the whole GTK+ or the Whole QT ? first of 
all lest analyse the way R3/GUI interface to win32 API it doesn't 
use that whole api specification it's limited to the ground management 
and rendering fonctions.

you have you windows manager API (win32, X11, Quartz)  then a brigde 
called the dialect that will parse your rebol files commands imputs 
and translate them to signal and calls to trigger the proper data/ 
functions calls to your window manager API

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

this looks to me like a lot of call to the win32 API  OLDES  !!!!

lol that point is just bumb justification to a bad choice oldes ... 
anyway not you are me will take any decision here since the project 
isn't in our hands

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.

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

Ok.. so we are in a big trable and I should dust of my PHP skills, 
that's what you want to hear?

btw... for your area-tc there was designed the R3's rich-text which 
you even don't give a try.

Oldes > "so what.. so try to make glut extension. what are you waiting 
for?" >> once again with the if your not happy do it yourself is 
that what a community should stand for? Problem is Oldes this debat 
I try now to start you should have started it like in feb 2010  and 
come with conclusion out of that ...  but no RMA took the project 
in hands and since then there is nothing more to talk about and that's 
serves your purpose because you only want minimal involvement in 
this matter

anyway for text processing who cares even having a GUI library ...

If the ground api isn't a problem then that' s again another reason 
to me to choose something else  that exists as same everywhere without 
need for you to change your C code  you just recompile it on the 
3 os and that's it .... Then we can talk  on  what is needed can 
a GTK+ or a QT 4  limited versions can fit our need. limited version 
means the ground functionnalities - widows management; display and 
event management -

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.

you talk about patience ... but problem is my patience would be filled 
if  there were a discussion about things choice futur  perspective 
documentation and not the way things are settling up since many month 
with a one sided discution you come with your own wishes fullfilled 
and you come here to show them and based on that get crowd admiration 
and support what you expect of us is being cheap beta testers nothing 
more nothing else...

I looked at  R3hostkit some month ago it was a mess ... I looked 
it now on the 110 it's still a mess  and there is no one here with 
a spine to have a technical level discussion with me !! as professionals 
how can you live with that ...!!??

it was added a web viewer...

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 
to:
-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?...

Cyphre - to get smooth (amiga-like) scrolling, with low CPU overhead 
(do you remember my scrolling news bar?), is your HW acceleration 
helpfull, or it would need any other specific links to DirectX stuff? 
Just a question ....

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 
project?

http://94.145.78.91/files/r3/gui/252.png


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.

btw what happened to the old R3 V2 gui from carl? could this be used 
as a starting point fpr another GUI?

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.

Even Pekr's dog knows, that a better path can always be found!

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

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.

A last note for ROBERT: I have read that r3GUI stiles will be developed 
until they are functional to the project specification the where 
created for. 

A clear, written, specific, development path to further develop these 
style and the missing other would be good to have a clear global 
view about the final goal apart this project specific development.

There doesn't need to be a specified development path from RMA for 
styles that are being developed outside of RMA. Independent cooperating 
projects are fine. We don't have to bog down the development process 
with too much management overhead.

Googledocs can turn a doc into html ...

Ah, so why Ladislav used such a format? Are those docs just an adaptation 
of Carl's docs? Or just to be later uploadable to official rebol.com 
site? OK, I can read plain text ....

GuiseppeC you got my ask wrong... developing in the dark as they 
do in Rebol3 is not a good thing... Problem in this project is that 
most of us are spectators ...

from the page of RM-Asset.com we can read and I quote:

What's special about RM-Asset?

We are very productive. This is good 
for you because we need less time than you might have thought.

We 
are very efficient. Internally we joke and say 
All good software fits onto a floppy-disk!"


We keep things simple. Our solutions are simple, easy to install, 
maintain and use. Most solutions are designed to complicated. We 
have streamlined designs making us faster while resulting in higher 
quality."


Fine but since you took over this proect we don't even have a prospective 
documentation (list of the widgets you want in it, the condition 
of this project, the stepstones on the road)or an api documentation 
etc... this means 0 lines of code. you claim to be the best to work 
fast to be serious. I just ask you to prove it.

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

As for the move to other toolkits. Reading some of your opinons, 
and not being good in low level details, I still dare to say, that 
you might get some things wrong. There would be imo no direct benefit 
in moving R3 Graphics to GTK+, Qt, etc. Most of those toolkits are 
just bigger. You also seem to overrate the difficulcy of porting 
View to different platforms. Just look at Steve Solie - he did Amiga 
port in nearly a no time - one month? Noone imo expected R3/View 
running on Amiga. All is needed imo is - free hands, knowledge, and 
will to do the port.

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

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.

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.

Nicolas, those 40 different OSes weren't really 40 different OSes, 
they were mostly different builds for at most a dozen different OS 
variants. Most of those OS variants are now no longer developed, 
or have changed so significantly that they are essentially different 
OSes now. The platforms that RT is actively supporting now for R3 
covers the vast majority of the current market, more than would be 
expected for an alpha product, and the host kit allows you to port 
it to the most obscure OS you want, as long as it can work on the 
scale that REBOL works at (not your microwave).


every computer and device (except iPhone) has a JVM in order to reach 
the mass market

 - Of the most popular smartphone platforms, only RIM and Symbian 
 (sometimes) have a JVM; iPhone, Android, WP7, and WebOS don't.

One naming tip - I noticed, in button.r3 source file for e.g., that 
we started to use multiple draw blocks? That's good. So - e.g. clicker 
style has two draw states (frames) - normal, and focus. Just a question 
- does "normal" sound good in english? Shouldn't be "default"?

we started to use multiple draw blocks?

 - they've been there for a good while now. :-) regarding naming, 
 I think it should reflect the specific state, rather than having 
 a "default". I usually prefer 'up, 'up-hover, 'down, etc. This is 
 easier to map to a state machine.

I doubt it is a good decision :-(

I think that every novice, when trying to change e.g. button color/border, 
find himself in a situation, when he influenced all buttons, etc. 
It was because direct path modification vs using make for subobjects. 
That is why I welcomed the move to declarative style definition, 
where the distinction could be made ...

OK - so - is there a need to distinguis local vs global style settings? 
Because in fact, I think that pushing user to use make edge [] just 
to prevent sharing, was pretty much crap in R2. That should be avoided 
if possible, as it creates burden on a user to know, that subobjects 
are shared in REBOL.

playing with draw blocks? - I thought that's a task for your dog 
:-)

Simply put - it is supposed to be a fun. We (rebol community) forgot 
about the fun a long time ago :-) I looked in some R2 demos, and 
was amazed - we need new demo contest, and the condition is simple 
- R3 only :-)

Question towards style tagging. I noticed some styles are tagged 
as 'internal, and some as 'compound. I would like to know, if it 
serves any other purpose, than for style listing/grouping, to distinguish 
it? 'Internal is probably just a tag, but does 'compound has any 
meaning further down in the code?

they are opposites. a 'compound style may not necessarily be 'internal, 
but may consist of 'internal faces. an 'internal face can be 'compound, 
but is not necessarily that.

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

1) make-panel does not accept third options argument anymore
2) the first two args are reversed

3) make-panel does not accept block (style) anymore, but a face object 
- I don't know how to do this one yet ...

I simply need to make a block with layout elements a face. Trying 
with make-face, but make-face accepts two arguments - style name, 
and options, I don't know what should I submit for the name ...

the interface was really nice:

make-panel: funct [
	"Create a panel from layout dialect block and options block."
	style [word! none!]
	content [block! none!] "Contents of the panel"
	options [object! block! map! none!] "Options of the panel"
][

My question still persist - how do I easily create a panel from a 
layout block? :-) Instead of one nice funcitons, which served well, 
I need to study  different concept, and make-panel is generally not 
usefull to average mortal :-)

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

trying to do some tests with Carl's demo, and it is going to be pain-in-the 
a..., to insert returns in there

 - that is an error, the group style is not the style Carl had, so 
 you should not do that at all

The style Carl named group was just a kind of a hpanel, with its 
box-model characteristics adjusted to not have a margin, IIRC

I can see you use empty rows...Aren't we wasting memory here?

 - how can an empty row waste memory? For example, I use empty to 
 make something like 'paragraphs' to group code parts that are somewhat 
 "related". E.g. if I resize a panel, the 'paragraph' resizing lines 
 precedes the 'paragraph' resizing columns, which is followed by the 
 'paragraph' resizing subfaces.

MIN/MAX-SIZE: I'm not fond of the idea of having the ability to set 
certain style variables in too many places. That said, setting them 
in styles rather than in layout is a decision that is hard to predict 
the outcome of, when using the styles in different layouts. I never 
really liked MAX-SIZE, but I suppose we can't get rid of it.

MAX-SIZE is totally necessary, if you want to have a resizing algorithm 
respecting the MAX-SIZE attribute.

none of my algorithms have max-size and its never been a problem 
in any layout I wanted to do.

though there is nothing stoping me from adding it to a specific frame 
variant within my stuff.  I've just never found it to be that usefull. 
in general, when you want max-size, actually what you want is static 
size.

(for a layout fragment)

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.  its better to have some of the things static 
which leaves space for the "space benefiting" areas.


then, whatever would need a max-size, should have a manual resize 
bar (which might be blocked so  but doesn't require support in the 
actual layout)

I haven't had time to play a lot with the latest R3.  though my notes 
are general in nature.

I've never, ever found MAX-SIZE useful for anything, because it doesn't 
fit intuitively in a layout situation, where there are much simpler 
means to produce a similar result. I suppose it makes sense for Carl 
in his old resize system, where MAX-SIZE was (shudder) tied to weighting, 
which produced some completely unpredictable results.

Well, relating MAX-SIZE to weithting was a bad idea, and we corrected 
that.

I haven't had time to play a lot

- then don't, just pick one example, try to resize the window, and 
see how it works.

no html needed when you just need to copy a part of it and do

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

 - not a big deal, really. My problem is, that what I want is behaviour 
 of panel style, but without gfx borders. But - I could create new 
 style, removing the visual elements of panel. Maybe such a style 
 could be added by default, but not sure others would find it usefull, 
 nor do I know what name to use ...

Of course, some styles might "prefer" to use the same MIN-SIZE/MAX-SIZE 
for all their faces, but it is not a general property.

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

Maybe such a style could be added by default, but not sure others 
would find it usefull, nor do I know what name to use ...

 - yes, that is possible. The difference between original, Carl's 
 implementation, and the new one is, that you have all the box model 
 attributes accessible, so you can do it easily now on your own.

re min/max-size, here's my take. I don't mind having both, not a 
big deal for me. But - when I tried Carl's examples back then,I tried 
on my nice Samsung FullHD TV. I maximised the screen, and wondered, 
why the heck fields don't resize properly. 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. So - as I know myself, my intention for max-size for the 
years to come will always be to cover FullHD displays. But as you 
can see, then it is artificial - I will simply use values, just to 
avoid effect I had with Carl's example.


As for min-size - I was negatively surprised by its removal, because 
I wanted panel of certain min-size to be displayed. But - I found 
there is new item, called initial-size, which fixed the situation 
for me ...

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

(that was a reply to pekr)

or, looking at it, we could temporarily make a work-around, until 
change is corrected

Did you have a look at the panels-20.r3 file?

Do we have a good documentation on how SHOW or screen updates occur? 
There is little point in the user having to figure this out himself 
to optimize display for speed.

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.