r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

BrianH
24-Jun-2010
[1681]
We're afraid because we've see some of these before, and they didn't 
turn out well. Specification dialects that don't require much specification 
and are easy to understand, make and maintain are preferred. If you 
were able to show us some layout dialect source with the resize specification 
markup, it would help a lot.
Gregg
24-Jun-2010
[1682]
It's very exciting though. I want to see it in action.
BrianH
24-Jun-2010
[1683]
Agreed :)
Ladislav
24-Jun-2010
[1684x2]
214 - vertical layout, in which all elements happen to have the same 
transversal size
(good to test the resizing accuracy)
Henrik
24-Jun-2010
[1686]
Davide, much harder actually, since I use virtual box on a mac. :-)
Gregg
24-Jun-2010
[1687x2]
Yes, that's what 214/215 seemed suited for.
Problems would show up very clearly.
Pekr
24-Jun-2010
[1689]
what I don't understand for the gui is, what panel and group are 
layered in different directions - vertical vs horizontal :-) (unrelated 
to resizing)
Ladislav
24-Jun-2010
[1690x2]
that is a principle, you can have layouts defined with the horizontal 
direction being the "major direction", or the vertical direction 
being the major direction, the former ones are groups, the latter 
ones are panels
216 is a more special layout in respect to resizing. It is defined 
so, that it can be resized only horizontally, and only the first 
and the last element are allowed to change their sizes when being 
resized. (that is something you cannot define in RebGUI as far as 
I know, neither it was possible in Carl's resizing algorithm, afaik)
BrianH
24-Jun-2010
[1692]
It was possible for Carl's original, but awkward. Don't remember 
if you could limit window sizing in Carl's original.
Ladislav
24-Jun-2010
[1693]
yes to "possible" in that you were allowed to specify it, no to "possible" 
you could obtain what you wanted
BrianH
24-Jun-2010
[1694]
Well whai I wanted was a non-awkward, minimal specification method, 
so a definite no to that. How's the dialect on yours?
Ladislav
24-Jun-2010
[1695]
Dialect is not fixed yet
BrianH
24-Jun-2010
[1696]
Ah. What are the factors in your algorithm? The semantic model is 
what I'm interested in.
Rebolek
24-Jun-2010
[1697x2]
The problem with Carl's original was that it was a good idea but 
it didn't work. That's fixed now.
Thanks to Ladislav and Cyphre.
BrianH
24-Jun-2010
[1699]
So, similar factors to Carl's? Size and max-size, group and panel?
Rebolek
24-Jun-2010
[1700]
yes, max-size is still there.
Ladislav
24-Jun-2010
[1701x2]
But, are you saying, that you could get a picture like 216 being 
scaled so, that the two boxes in the middle do not change their sizes, 
while the first one and the last one do so, that the boxes remain 
next to each other all the time?
(Cyphre was pretty sure, it was not possible)
BrianH
24-Jun-2010
[1703]
I am not asking about the math - I trust you and Cyphre to make the 
math absolutely perfect. I am at the moment asking about the semantics 
of the resize model
Ladislav
24-Jun-2010
[1704]
yes, but I was asking, whether that layout was possible, expressing 
the opinion it was not, but I may be wrong, of course
Rebolek
24-Jun-2010
[1705]
I don't like max-size, but the way it's done now, I think, that it 
can be omited from style-writing and R3/GUI can take care of it. 
But that's just a guess right now. There's now code to support my 
guess.
Ladislav
24-Jun-2010
[1706]
factors: min-size, max-size, group, panel
Rebolek
24-Jun-2010
[1707]
now=no
BrianH
24-Jun-2010
[1708]
It was theoretically possible with Carl's resize model - ignoring 
whether the math worked - but it was really awkward to specify. That 
is my main concern.
Ladislav
24-Jun-2010
[1709]
Rebolek, actually you are wrong, you cannot define layouts with elements 
having max-size/min-size without having a direct support for these 
features (maximally, you can get some "ugly approximations", but 
surely not the same behaviour)
BrianH
24-Jun-2010
[1710]
The main problem with Carl's resize model was that it was difficult 
to specify proportional scaling independent of max-size. This made 
layouts fail on unexpectedly large screens, or made it necessary 
to put in a lot of very large numbers in max-size.
Ladislav
24-Jun-2010
[1711]
That dependency does not exist in the new resizing model
BrianH
24-Jun-2010
[1712]
Well then that is really good news :)
Ladislav
24-Jun-2010
[1713]
And, yes, that was a motivation for me to invent something more convenient
Rebolek
24-Jun-2010
[1714]
I know I'm wrong regarding the min-size, but not the max-size.
Steeve
24-Jun-2010
[1715]
I just think  proportional resizing feature is the problem. It's 
usually useless and hard to code.
Graham
24-Jun-2010
[1716x2]
re language support .. I think primarily faces have to adjust for 
different lengths of text
when you translate from one language to another
BrianH
24-Jun-2010
[1718]
Hard to code, yes. Useless, no, not unless you're on a fixed-size 
screen.
Steeve
24-Jun-2010
[1719]
Proportionnal resizing without font resizing has no use, IMO.
Ladislav
24-Jun-2010
[1720]
Well, Steeve, you do not have to use it, but it will be available 
in case it is needed
BrianH
24-Jun-2010
[1721]
Steeve, that would defeat the purpose of buying a large screen so 
you can see more stuff. Used a spreadsheet lately? Graham, that can 
change the whole layout. If it autoadjusts, cool, but you'd at least 
need different layouts for languages that go in different directions.
Steeve
24-Jun-2010
[1722x2]
I do no  say we don't need resizing
*not
Graham
24-Jun-2010
[1724x2]
well I think I'll restrict to languages that go from left to right
and are horizontal
Rebolek
24-Jun-2010
[1726]
It's not proportional resizing ONLY, if you want your elements to 
stay whey they were, you're free to do so.
Graham
24-Jun-2010
[1727x2]
Chinese used to be right to left and top to bottom... but I think 
they've changed
Is Arabic still right to left?
Steeve
24-Jun-2010
[1729]
But the old way (fixing the corners to the container) is goog enough.
Rebolek
24-Jun-2010
[1730]
Graham: yes, but AFAIK, they write their numbers mostly L->R. Strange.