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

World: r3wp

[!REBOL3-OLD1]

Pekr
9-Oct-2008
[7284]
According to your words, it seems that you and Henrik have access 
to the code, right? :-) Have you studied Gabriele's VID too? How 
do those compare?
Henrik
9-Oct-2008
[7285]
I have no access to the code.
Pekr
9-Oct-2008
[7286]
but how would BrianH know details about new resizing model, not having 
the code? :-)
Anton
9-Oct-2008
[7287x2]
Carl does write occassionally..
occasionally
BrianH
9-Oct-2008
[7289x4]
Since I have implemented resizing models in the past, Carl discussed 
his new model with me when he came out of hiding. I don't have access 
to the code yet, but I can figure out things based on knowledge of 
REBOL, conversations with Carl, and mostly his writings and docs.
Petr, I am aware of the TeX model and its tradeoffs.
Every system is built on compromises, even TeX and Gabriele's VID. 
The trick in design is making the right ones.
Actually, make-gobs was implemented to make the UI fast. Gabriele's 
VID had to do a lot of calculations in the Draw blocks, and when 
you combine that with the resize overhead it added up. He added make-gobs 
to precalculate some of those Draw calculations.
Pekr
9-Oct-2008
[7293]
Interesting. VLC player 0.9.2 used cross-platform own file dialog, 
0.9.4 uses native one.
Gabriele
13-Oct-2008
[7294x3]
Brian, I disagree that my system was slow. Indeed, I don't think 
you can do it much faster unless you make it more low level (ie. 
users need to specify more). Even then, I still think the speed would 
be the same.
make-gobs wasn't required
 - let's see what happens when Henrik tries to add his graphics.
Brian... it's not like my vid had to do a lot of calculations. ANY 
VID will have to do a lot of calculations. You can write all that 
manually (my proto2) or have a system that writes the code for you 
(make-gobs). There is no third option (well, you could interpret 
instead of compiling in something like make-gobs, but you won't like 
that).
Henrik
13-Oct-2008
[7297]
I never got the chance to try out make-gobs, but it did seem to solve 
a complexity problem on the DRAW level by giving it for example an 
internal resizing model, which is very important for properly made 
GUI graphics..
Anton
13-Oct-2008
[7298]
Hmmm........
BrianH
13-Oct-2008
[7299x2]
Gabriele, you can make it faster by simplifying the resize model, 
thus needing fewer calculations and less precompilation.
A simpler resize model is also easier to write code for - less fiddly 
for the less supreme programmer.
Gabriele
14-Oct-2008
[7301x4]
I may have not been clear. Given the goal of having the system figure 
out how to best resize in all conditions, I don't think you can make 
it simpler or faster; the TeX model is the simplest and fastest (because 
you can precompute most of the values) that I know.
If you have a different goal, then you can be faster. For example, 
if you use something like my make-gobs for faces too, then you can 
compile a resize function that will be as fast as if it was hand-written 
(if you optimize well).
That is a simpler resize model in that you have to specify all the 
constraints yourself, and it does not do tabular alignments automatically 
for you.
When you want tabular alignments, I don't think you can do much better 
even if you code the resize function by hand, with the exception 
of special cases like all faces being the same size and things like 
that.
Robert
14-Oct-2008
[7305]
Gab, do you plan or already do continue your VID approach? I think 
we have to do some trade-offs between what VID can do in terms of 
simplicity and features.


I think we should try your approach and Carl's on a realy world app 
to see what fits best. Maybe it's a good idea to have a Simple-VID 
(for smaler tools) and a Fullfledged-VID (for big apps).
Pekr
14-Oct-2008
[7306]
... especially in the case when Gab's VID was 90% complete?
shadwolf
14-Oct-2008
[7307x7]
robert why not  but that will make again another rebolVM split  how 
to differencie what VID  version the app you are  going to use need
don't that will lead to a "Ho man that program is bugged it crash 
when i try to use it !!" and in fact the rebol script just needs 
the VID++ 2  turbo alpha ++ version
the rebol politics is rebol is all you need to do software
I'm agree that's a pity to abandon a work such advanced  and that 
demotive alot the comunity
gabriele worked hard to get his new VID and when it's all most complet 
Carl come with a better plan and trash out Gab's work that's not 
a good example to motive the comminuty to participate on further 
project where rebol content is directly conserned
How about adding the GAB  VID into ORCA ?
i'm sure Sillabe would like it even if Carl doesn"t
Henrik
14-Oct-2008
[7314x3]
I'm now able to study the R3 GUI source code.
As far as I can tell there are animation effects in it as well as 
a small suite of debug tools. Each source file is really small, around 
2-8 kb with a few going above 10 kb. Fully commented and very clean.
Running the GUI now. It's... colorful :-)
Graham
14-Oct-2008
[7317]
elastic?
Henrik
14-Oct-2008
[7318]
meaning?
Graham
14-Oct-2008
[7319]
resizing is automatic and good?
Henrik
14-Oct-2008
[7320x6]
resizing is automatic, but buggy. there is a list of known bugs.
there are animations in the GUI and I can resize the entire window 
while they play.
They are transitional animations and are fully interruptible.
http://rebol.hmkdesign.dk/files/r3/gui/001.png

Skin is for testing purposes.
Carl says the animation system is a simple prototype.
Mostly because events are not yet pushed correctly to it. So it's 
an event based animation system.
Graham
14-Oct-2008
[7326]
automatic scrollbars?
Henrik
14-Oct-2008
[7327]
meaning?
Pekr
14-Oct-2008
[7328]
aaaah, what a mixture of colors :-)
Henrik
14-Oct-2008
[7329]
Pekr, well, that's Carl's work. :-)
Pekr
14-Oct-2008
[7330x2]
so we've got "transition" effect? What are they used for?
.e.g. change of tabs/windows?
Henrik
14-Oct-2008
[7332]
The GUI feels fairly quick, but Carl says there is still a lot of 
optimization and caching to be done. This won't happen until he feels 
the entire system works correctly.
Pekr
14-Oct-2008
[7333]
btw: what do you mean by "each source file" - is the code now organised 
more in the RebGUI way? E.g. each "widget" being one file?