AltME groups: search

Thanks, that changes the picture

Giuseppe, in the context of REBOL as a messaging/data language, can 
you picture how it might work as a class-based model? And do you 
think a class-based model is more appropriate in distributed environments?

cyphre unfortunatly  win32API is abandonned on vista and  seven (widows 
6 and 7) so the font rendering is not good look at the picture here 
that shows the differences

@Gregg:  when I imagine Ladislav and Cyphre working like that on 
code, I picture a slow motion movie scene with epic music  thumping 
in the background, lots of dramatic cuts between close up face shots, 
etc...

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?

It seems I posted the wrong links. I meant picture 226 and 227, not 
225 and 226.

Do you have a picture for the other orientation?

Its not alignments, its coordinate system.

With alignments the movie picture is glue to a border or centered 
in both direction.
With coordinate the picture itself would be mirrored in H or V !

cause the picture size had to be small and since their is auto resizing 
that means nothing ...

Yes, and that is exactly the thing we are missing - the big picture. 
Noone said there's anything wrong with Rich Text, para handling, 
etc.

Rebolek - I will be harsh, but others might feel, that what is waste 
of time is lack of communication and providing big picture. You accepted 
SCRUM methodology, but only for your team internal purposes. The 
rest of us knows nothing about what's happening at particular levels. 
If you stop informing ppl, then the only thing we would know about 
the GUI would be, that team of 4 ppl are working on it for 4-5 monts, 
with no visible result. Ppl are very eager to have GUI.

As for me, I can imagine Henrik doing much more important work, especially, 
as we have just few basic styles, which are even not working properly 
yet. But - we can't see the big picture. Henrik's work can go in 
parallel, and I think that Robert is sane enough to know what he 
is doing/requesting and why. That means - we have to be missing something 
...

i saw your first teapot picture any improvements since then ?

My whole point was, that Carl took some rewrite route back then, 
and in 2-3 months timeframe produced kind of basic, but working GUI, 
which could be demoed by 'demo function of R3, while with R3 GUI, 
we are not there yet. I don't need to be pointed out to such facts, 
that 2 years old GUI apparently does not work with latest R3 builds 
:-)


Also - "you can wait ... or be active on your own ..." is not an 
argument for me. Noone apart from maybe 1-2 guys here want to work 
on yet-another GUI project. The whole thing is about me (and maybe 
others) not seeing a "big picture" - things plugging-in together 
into useable form timeframe. I know that giving any terms is very 
tricky, but my point was not to get exact nor even estimated date 
- just some rough ideas about what's still left to be done ....

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

They are important to discuss and you will not get every wish granted, 
but it's only a matter of seeing the big picture of things.

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


http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23

http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/
http://www.linuxmint.com/screenshots.php

Take it just as a note :-)

It was a bad picture. Now I need mind bleach.

Thanks for doing the func-with-init research Ladislav. While I think 
we sometimes focus too much on optimization, I can see this as being 
important in the big picture for writing function generators that 
produce efficient results.

and most likely some super complex healthcare standards do, which 
is where graham enters the picture :)

primitives will have the possibility to setup run-time manipulators, 
which modify the internal primitive data on their own.  


this means you might not even notice that there is a frame jump in 
setup because the manipulators are still active, using the old data.... 

ex:  

'PRIMITIVE-A  has a targeting manipulator which keeps this model 
always aiming another model, 

'PRIMITIVE-B has a manipulator using a constant speed which ends 
up moving it in space.


now picture a situation where the scene update where taking longer 
than the sleeping time (or it just started at the wrong moment and 
occurs just before rendering starts).

if the main thread where responsible for triggering the refresh, 
you would see a noticeable lag. 


 but with this setup,  both primitives  would still continue to move, 
 while the speed is adjusted... when all the setup is done, the renderer 
 knows it can update and it then adjusts its internal data to reflect 
 the high-level changes made by the main thread.


the manipulators are C functions, so they will be very fast.  (there 
will be a special REBOL callback mode for testing, but it will be 
much slower)

inter-para indenation would be defined by the para/indent/y (specific 
for each para) and origin/x (defined for the whole gob) as it is 
on the picture in the doc.

(see the picture)

this one is just quickly sketched..I'll be redoing the current picture 
in the doc to show  it  all better and with updated names etc.

Does anyone know who's the author of the "rebolution" image I've 
used on slide 4? I had that picture on my disk, but can't find it 
online. I wanted to give proper credits to its author.

They do on the older picture...

This would be similar to what MAKE does on an object's spec block! 
but a bit smarter as you need to dive into function! values (MAKE 
doesn't do that AFAICT). You need to see the distinction between 
"unevaluated code" (source form) and "evaluated code" (reduced form) 
to get a clear picture on this issue.

Doc it would be very helpful to publish (maybe as picture) workflow 
thru respective modules (files) because for non expert it is quite 
difficult to see what is going on each module.

@TomBon Great ! I like this picture !

The Map is the current picture of what's implemented, so it's not 
an image of all for version 1 of World. As I mention in the README 
on GitHub, date! and time! is only partly implemented, the rest is 
more or less completed for version 1.

I would like to improve the Map, so I'm working on that.

We are aiming for a purely syntactic description. So semantic checks 
at a later stage are out of the picture for now (no action blocks 
in general, and here: no loading of digits in particular).