World: r3wp

though I haven't played around with the latest versions...  and its 
been a very long time, so it could be that I tested it just before 
my vista install crapped out.

but the true thing is windows XP have  10  years now it's more than 
deprecated OS. If the font probleme on R2 cant't be solved ok i'm 
ready to wait other year to get a R3 draw/font relation working perfectly 
everywhere. The lessons of area-tc are:

1)

1) it's possible

1) it's possible for AGG to deal text rendering evolved at a low 
level (perf are great  on R2 and that's convincing)

2) Since draw wasn't made to handle such an extensive use of the 
draw/text instruction  in R3 we have to make the AGG mode adapted 
to block of text handelling the first idea and the main  boring thing 
to have to deal in AGG text rendering is the positioning of every 
block of text. We need a way to retrieve the position of a texte 
on screen.  

3) to be better and faster AGG should be less verbose. I know that 
it's possible to save lot of space in the draw block

4) the font system should be able to used every where

I think we just spend our effort on R3

Shadwolf,

re glyph engine in R2: The glyph manager is used inside DRAW dialect. 
But the internals were never exposed at the REBOL laguage level. 
Should I really explain why? I hope not.


R3 text improvements: As I wrote week ago here to you on AltMe there 
are no limits for you to make it happen. You can already build your 
own font engine+dialect in C/C++ or whatever and use it as EXTENSION 
for prototyping your contributions. If I was able to protoype using 
R2 dll interface you have now even more possibilities. So where is 
the problem?

Regarding the XP vs VIsta and 7 issue:

I'm repeating it again. If you are able to see the bug, then please 
give us something more that screenshot or long confusing posts...trace 
log file with the differences in returned values or whatever,  simple 
clear example proving that the error is really in carret handling 
native functions....That would really speed up possible bugfix or 
at least clarify the issue. Is it so hard to understand this?


Hope my words doesn't look rude. I want to help you as much as I 
can...we seems to have just some disconnect here.

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

Maybe it's even possible to mix the current and simple "add action 
to widget" pattern with such a event based system.

I have used such an approach in one of our apps.For example I have 
three tables, that depending on the app state, show different columns 
and data. So, when app state switches this will trigger the change 
of the tables.


And other example is changing the language just where you are. No 
need to re-enter the current GUI etc. There will be just a change-lang 
XY event send.

Wasn't Max proposing a message passing gui in one of his various 
liquid thingies?

liquid is a message passing engine, but its complex to use in guis 
as-is.  it can be done (as I shown a few times) but requires a dialect 
or api over it to manage it.

just to make it simpler to use in real world use.

the advantage is that its a generic engine... and can be used to 
link up any aspect of an app. not just its "actions"

for example, right now, in my pain application, if you replace the 
bg-image of the canvas, it refreshes the whole software on its own. 
 the size of the canvas, the crop bars, image properties and input 
management offsets, etc, etc.

but in this app there is no dialect of api beyond the shape/graphic 
element management.

so its not readily obvious just how much goes on in the application 
without following the links in the code.

this app will be released this week.

no pain no gain

I think we just need to finish R3 GUI as Carl started it (VID 3.4). 
We might think about some by Max proposed enhancements to Draw, making 
GUI kernel more powefull, and let's see, where it leads us, before 
we start to think about another overhaul. Msg passing concept is 
surely interesting, but it imo creates another layer to implement, 
understand, to work with, so I am just not sure, unless I see the 
currently implemented solution does not allow us to easily work/extend 
the GUI.

exactly what I think.  keep it simple for now... once liquid is revamped 
for R3 we can see how I can make a module to add it so view 3.4, 
just like I did for view R2.

by Draw enhancements above, I mean proposal by max, making it "first 
class citizen", so removing the overhead of draw dialect ... but 
that is for gurus to think about :-)

see msg 8-Jan, 15:34

Carl's original goal for the GUI was to make it so a child could 
use it. We should not deviate from that goal. That's part of what 
Rebrowse is meant to do. I don't want to risk a forking of the GUI 
work.

I don't mind advanced features at all, but we must be careful not 
to make the GUI difficult to use from the outset or having to place 
the user into a specific mindset, when starting to learn it.

there is VID and there is View.  we must not sacrifice the later 
for the former.

exaclty. I think that VID3.4 is designed in a good way, let's first 
see, if the architecture provides us everything we need ...

to me VID always very easy to use.  making it pretty & dynamic ... 
well that's a bit (a lot ;-) more painfull.

I think it's possible to make it strong for industrial strength applications, 
without making the usability a hindrance. I also wouldn't want to 
lose the ability to write a GUI in 2 minutes for your boss to use.

We all agree on that, but I just want to raise the point that a lot 
of the short commings in view are based on some serious issues in 
VID.

oops... hehe shortcommings in VID are based on those in View... heheh

view is already much more powerfull now, but I feel that the current 
design is like going half way. 


instead of having a totally open level 1 (gfx engine) on which level 
2 (view) and level 3 (VID) is built, we have level 1.5 and level 
3

and I mean within REBOL, not within C.

Most of VID's serious issues come down to event handling (solvable 
now) and incompleteness (also solvable, just a bunch of hard work) 
and missing features, like keyboard navigation (already solved that). 
The VID extension kit makes VID much more scalable, simply by finishing 
the work that Carl set out to do. It's easier to write large apps 
because styles are more uniform, and you have more powerful features 
and adherence to face accessors, rather than relying on face hacking.


Building those features into V3.4 by default, and you have a killer 
UI system without sacrificing usability.

glayout already implements 90% of what we want to build for VID 3.4, 
down to the dynamic layout engine, which is just about the same.

themes are a 2 function addition, and localisation would be a single 
function to add.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

but VID R2 has some very serious platform limits which we can bypass... 
which is nice to be able to have access to in the next implementation 
of R3 View which is outside the core dll.

can=can't

Max - so what do you propose for the kernel, to not be 1.5 and 3, 
but 1, 2, 3? :-)

:-P

it could be 1, 1.5, and 3 also if people like how gobs are currently 
structured. :-)

so what comes into "1"? :-)

gels = graphic elements

We already have message passing, and these messages are events.

So, maybe we need to have the ability to define custom events and 
have custom event handlers.

I was never convinced by Max's liquid thingy as even as the author, 
he was not readily able to cook up anything other than the most simple 
of demos.

As for semantic meaning in styles ... I think that remains to be 
proven

Graham - IIRC, custom generated events were planned since the very 
beginning? But they are not probably implemented/enabled yet .....