Re: Re: about your concept

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> maybe a pdf rendering model would be good idea? That looks like a generic
> widget drawing facility to me.
Well, it's basically a good idea in my oppinion. The issues I can see 
regarding PDF are speed, legal issues, and dynamic content.

To explain what I mean with dynamic content, take simple scaling as the first 
example. Imagine we would like to use a simple drawing primitive and store 
that code on the server. Let's assume we'd like to store vector instructions 
to draw a flower. (Can anyone say ICQ-client?) It is easy to see that this 
flower have two important parameters required to draw it. Height and width.

I think PDF could support scaling, even without keeping aspect excellent. So 
let's move on to another example. Imagine we'd like to use a progress-meter. 
(Stupid idea, since Y hopefully will include it's own progress-meter, but I 
could for instance imagine that webpages might require custom-themed widgets 
that fits into the theme of the webpage. HTML certainly allows it.) The 
primitive would then require 4 parameters: length, thickness, orientation and 
progress.

As I see it, Y could greatly benefit from supporting these kinds of parametric 
drawing primitives. To get back to the ICQ-example, most ICQ-applications do 
display status by the color of the flower. As I see it, colour could just be 
another parameter.

When I think about it, I think this might be something that should be 
considered for implementation throughout the entire graphics-drawing system. 
I've got a feeling it might be something like this Phil had in mind when 
talking about identifying common primitives for the widgets. Am I close, 
Phil?

Imagine it would be possible to provide a bunch of primitives in the server. 
Let the primitives with an id below 32k or something be reserved for core 
primitives, primitives that are replaced when switching themes. These 
primitives could then be used to build core widgets like buttons, menus etc. 
Exchange these primitives with primitives from a different theme and you've 
got yourself a completely different-looking widgetset. Then let the 
primitives above 64k be contributed by client-applications as they connect, 
to increase their performance and latency when redrawing their custom 
widgets. Let the primitives take parameters, and hopefully not as many 
primitives will be required, at the same time as flexibility for the 
theme-writer increases. One other nice side-effect of this setup would be 
that custom widgets still could use themed primitives and thereby get a 
themed look. Yet another bonus of letting the primitives take parameters 
would be that applications such as a webbrowser that might have to override 
the system-global theme can quite easily build a quite cheap set of own 
primitives and send to the server, and then simply passing them the 
parameters it parsed from the HTML. (Color, border thickness etc.)

Perhaps it could even be extended to make some of the parameters of the core 
primitives optional, defaulting to the current color-scheme etc, but allowing 
special applications such as our webbrowser to still use them. I'm not sure 
we want to allow this though, for UI consistency-reasons as well performance.

Well, this was quite a heavy chunk of ideas. I'll shut up for tonight, but 
please come with constructive feedback. And Phil, please let me know if I'm 
somewhat on track with what you had in mind for themeing/primitives.

Regards
/ Ulrik

- -- 
QOTD:
	"I may not be able to walk, but I drive from the sitting posistion."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBABs/069SELtZwIkRAg0LAJwPSOO9XfItXZxRmnqmY4S2XJedKwCeJJoM
BJgN/mMLOO+cv0JlmiCTb+Q=
=cMht
-----END PGP SIGNATURE-----