Menu
▾
▴
severage-isvg — discussions of the iSVG extension language
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(41) |
Oct
(3) |
Nov
|
Dec
(1) |
|---|
|
From: Antoine Q. <an...@gr...> - 2001-09-18 18:18:47
|
> Have you turned on notification of new subscriptions ? I'd > like to know about > it if Bob joins ;-) Yes, if Bob is DiBlasi, his posts will be moderated!!! > > I already have a routine that does this king of awful > thing, but I'll > > check with the man (Peter) first. > > If you don't mind testing the version I gave you that adds a > method to the > String interface it'd be great. I'd love to know whether that > approach works. > Using that we'd be able to have very readable and clean code. Well, if there is no way to do it with split, then it's going back in the code! What would the Perl split do in the case I described? antoine |
|
From: Robin B. <ro...@kn...> - 2001-09-18 18:13:05
|
On Tuesday 18 September 2001 20:07, Antoine Quint wrote: > Antoine Quint > Robin Berjon > Julien Quint > Stephane Bonhomme Hi gang ! > I guess when we'll go public in the coming weeks there will be more > people. Have you turned on notification of new subscriptions ? I'd like to know about it if Bob joins ;-) > I already have a routine that does this king of awful thing, but I'll > check with the man (Peter) first. If you don't mind testing the version I gave you that adds a method to the String interface it'd be great. I'd love to know whether that approach works. Using that we'd be able to have very readable and clean code. -- _______________________________________________________________________ Robin Berjon <ro...@kn...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- An eye for an eye will make the whole world blind. -- Mahatma Gandhi |
|
From: Robin B. <ro...@kn...> - 2001-09-18 18:11:06
|
On Tuesday 18 September 2001 19:58, Antoine Quint wrote:
> node_list.item(i).hasOwnProperty('style') works great! Where did you
> find info about this?
The E262 is a PITA to read (it's targetted towards implementors) but it's the
total spec, and contains everything.
From what I understand, OO in E262 is completely prototype based. That is, a
random string has the prototype of String, etc... Now you have this thing
that is called the Object object, from which all other objects derive (I
still haven't figured out how that derivation works, but perhaps someone here
is expert enough in type-based oo to explain it kindly to me).
Object has the hasOwnProperty method which is there to check for the presence
of a property (what you get through accessors like getFoo()). So I guessed
that it had to be available to all objects.
> Also, this example:
>
> var props = '';
> for (p in element) {
> props += p + ': ' + element[p] + "\n";
> }
> alert(props);
>
> Looks great but I don't understand what it does, where is p coming from?
This is a much more classical usage of E262. The 'in' is key here, it's an
iterator over 'element''s properties. For every iteration, p is simply the
name of the next property (which likely includes methods, as methods in E262
are simply executable properties). In turn, element[p] is the value
corresponding to that property.
You can also do that in your browser, I often use it to debug weird
behaviours.
Hey, it looks like I might be becoming an E262 expert. S**t, I hope news of
that don't spread to the Perl community or I might just as well switch to
Python as well ;-)
--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi
|
|
From: Antoine Q. <an...@gr...> - 2001-09-18 18:07:08
|
> Welcome ! Who else is here now ? The four of us: Antoine Quint Robin Berjon Julien Quint Stephane Bonhomme I guess when we'll go public in the coming weeks there will be more people. > If I can read E262 correctly, ASV's implementation is the > correct one (you > might want to check this with Peter on svg-dev). Of course, > E262 is a stupid > standard and a little more dwimity would be nice but this is > no reason for > IE6 to break the standard. That's what I was thinking. I already have a routine that does this king of awful thing, but I'll check with the man (Peter) first. antoine |
|
From: Robin B. <ro...@kn...> - 2001-09-18 18:02:31
|
On Tuesday 18 September 2001 19:27, Antoine Quint wrote:
> This one might be solved by either of you (now that Stephane and Julien
> have joined).
Welcome ! Who else is here now ?
> I'm trying to split this string: "rgb(255,0,0)" into an array [255,0,0]
>
> I'm using EcmaScript with the Adobe SVG Viewer 3.0 scripting engine
> "split(/\D+/)" to split that string, but the array returned is
> [,255,0,0,] !!!
>
> IE 6.0 does the split as I expect it...
>
> But which split implementation is the correct one?
If I can read E262 correctly, ASV's implementation is the correct one (you
might want to check this with Peter on svg-dev). Of course, E262 is a stupid
standard and a little more dwimity would be nice but this is no reason for
IE6 to break the standard.
Suggested workaround:
/* this is totally untested, but it would be great if it worked */
function isvgNonNumericSplit () {
var preClean = new Regexp('^\D+');
var postClean = new Regexp('\D+$');
this.replace(preClean, '');
this.replace(postClean, '');
return this.split('\D+');
}
// add to the interface
String.prototype.isvgNonNumericSplit = isvgNonNumericSplit;
Of course, chances are that may not work. If so then we're left with the old:
function isvgNonNumericSplit (str) {
var preClean = new Regexp('^\D+');
var postClean = new Regexp('\D+$');
str.replace(preClean, '');
str.replace(postClean, '');
return str.split('\D+');
}
Which looks very similar, except that the former can be called directly on
the string as in mystring.isvgNonNumericSplit() where the latter can only be
called as isvgNonNumericSplit(mystring). If possible I think we should use
(everywhere) the former.
Has anyone figured out how inheritance works in E262 ? Or if it's only
possible ?
--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi
|
|
From: Antoine Q. <an...@gr...> - 2001-09-18 17:58:14
|
Dude,
node_list.item(i).hasOwnProperty('style') works great! Where did you
find info about this?
Also, this example:
var props = '';
for (p in element) {
props += p + ': ' + element[p] + "\n";
}
alert(props);
Looks great but I don't understand what it does, where is p coming from?
antoine
|
|
From: Robin B. <ro...@kn...> - 2001-09-18 17:40:31
|
On Tuesday 18 September 2001 19:41, Robin Berjon wrote:
> Give element.prototype.hasOwnProperty('style') a try, and then go for eval.
> You might want to check the elements' interfaces for other clues:
You might want to also try the above without the '.prototype'.
--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi
|
|
From: Robin B. <ro...@kn...> - 2001-09-18 17:38:31
|
On Tuesday 18 September 2001 19:32, Antoine Quint wrote:
> > This is extremely expensive, are you sure there's no better
> > way ? Wouldn't
> > you be able to specify the targets on the gradient or
> > something like that ?
> >
> > <i:gradient>
> > <i:target xlink:href='#foo'>
> > <i:target xlink:href='#bar'>
> > </i:gradient>
>
> Of course, I could do that... But I really want to keep it as simple as
> possible, and since there was a way to avoid doing this...
I think the best aproach is: make it work first, then think about making it
simpler. I don't think people care about having to add (most likely
cutnpaste) a few elements. If there is a better, not too expensive, way we
can always add it later on as extra sugar.
> I may rethink the syntax then. How about doing:
>
> <rect style="fill:url(#my_gradient)">
> <i:gradient xlink:href="#k_gradient">
> <i:target xlink:href="#target" attributeName="fill" />
> <i:target xlink:href="#target" attributeName="stroke" />
> <i:target xlink:href="#coords" attributeName="fill" />
> </i:gradient>
> </rect>
>
> This way we would now what is the gradient holder (the parent node).
Looks good to me.
> A dirty trick works sometimes, and that is checking
> hasAttribute('style'), but it completely defeats the purpose of CSS
> since this would not support cascading. The eval way might well be the
> least awful option.
I vote against hasAttribute, it does indeed totally defeat everything that we
belive in. It is weak and without honour.
Give element.prototype.hasOwnProperty('style') a try, and then go for eval.
You might want to check the elements' interfaces for other clues:
var props = '';
for (p in element) {
props += p + ': ' + element[p] + "\n";
}
alert(props);
--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi
|
|
From: Antoine Q. <an...@gr...> - 2001-09-18 17:32:00
|
> > In the gradients module, there is a function called at init
> that looks
> > up the DOM tree for the shapes filled with the gradients that are
> > i:gradient enabled. So what I do is look through
> > doc.getElementsByTagName('*') and I check each element's
> "fill" property
> > to see if it refers to the specified gradient.
>
> This is extremely expensive, are you sure there's no better
> way ? Wouldn't
> you be able to specify the targets on the gradient or
> something like that ?
>
> <i:gradient>
> <i:target xlink:href='#foo'>
> <i:target xlink:href='#bar'>
> </i:gradient>
Of course, I could do that... But I really want to keep it as simple as
possible, and since there was a way to avoid doing this... I may rethink
the syntax then. How about doing:
<rect style="fill:url(#my_gradient)">
<i:gradient xlink:href="#k_gradient">
<i:target xlink:href="#target" attributeName="fill" />
<i:target xlink:href="#target" attributeName="stroke" />
<i:target xlink:href="#coords" attributeName="fill" />
</i:gradient>
</rect>
This way we would now what is the gradient holder (the parent node).
> > Problem is that before I
> > read the "fill" property I need to check if that particular element
> > allows for the Style interface (getStyle()) to be called.
> >
> > Anybody knows how to do this?
>
> I'm presently looking into ways of making E262 really OO, and
> it's not
> looking nice (it's even less OO than Java !). You might try
> element.prototype.hasOwnProperty('style'), that should
> normally tell you
> whether your object has a property called style, which is needed by
> getStyle(). However I wouldn't be surprised if it didn't
> work. Another option
> is to do the tricks people do in browsers (eval'ing to see if
> it works,
> testing the returned value to be an object, etc). Also note
> that it is
> possible -- though marginal -- that an element would have a
> getStyle() method
> that is not what you expect (this could happen with embedded
> XHTML for
> instance). That could have nasty side-effects (as most abuses
> of polymorphism
> would).
A dirty trick works sometimes, and that is checking
hasAttribute('style'), but it completely defeats the purpose of CSS
since this would not support cascading. The eval way might well be the
least awful option.
antoine
|
|
From: Antoine Q. <an...@gr...> - 2001-09-18 17:27:08
|
Hey, This one might be solved by either of you (now that Stephane and Julien have joined). I'm trying to split this string: "rgb(255,0,0)" into an array [255,0,0] I'm using EcmaScript with the Adobe SVG Viewer 3.0 scripting engine "split(/\D+/)" to split that string, but the array returned is [,255,0,0,] !!! IE 6.0 does the split as I expect it... But which split implementation is the correct one? Thanks, Antoine |
|
From: Robin B. <ro...@kn...> - 2001-09-18 17:23:05
|
On Tuesday 18 September 2001 18:51, Antoine Quint wrote:
> In the gradients module, there is a function called at init that looks
> up the DOM tree for the shapes filled with the gradients that are
> i:gradient enabled. So what I do is look through
> doc.getElementsByTagName('*') and I check each element's "fill" property
> to see if it refers to the specified gradient.
This is extremely expensive, are you sure there's no better way ? Wouldn't
you be able to specify the targets on the gradient or something like that ?
<i:gradient>
<i:target xlink:href='#foo'>
<i:target xlink:href='#bar'>
</i:gradient>
> Problem is that before I
> read the "fill" property I need to check if that particular element
> allows for the Style interface (getStyle()) to be called.
>
> Anybody knows how to do this?
I'm presently looking into ways of making E262 really OO, and it's not
looking nice (it's even less OO than Java !). You might try
element.prototype.hasOwnProperty('style'), that should normally tell you
whether your object has a property called style, which is needed by
getStyle(). However I wouldn't be surprised if it didn't work. Another option
is to do the tricks people do in browsers (eval'ing to see if it works,
testing the returned value to be an object, etc). Also note that it is
possible -- though marginal -- that an element would have a getStyle() method
that is not what you expect (this could happen with embedded XHTML for
instance). That could have nasty side-effects (as most abuses of polymorphism
would).
--
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
An eye for an eye will make the whole world blind. -- Mahatma Gandhi
|
|
From: Antoine Q. <an...@fu...> - 2001-09-18 16:51:06
|
Hey,
In the gradients module, there is a function called at init that looks
up the DOM tree for the shapes filled with the gradients that are
i:gradient enabled. So what I do is look through
doc.getElementsByTagName('*') and I check each element's "fill" property
to see if it refers to the specified gradient. Problem is that before I
read the "fill" property I need to check if that particular element
allows for the Style interface (getStyle()) to be called.
Anybody knows how to do this?
antoine
|
|
From: Robin B. <ro...@kn...> - 2001-09-17 15:00:29
|
On Monday 17 September 2001 10:14, Antoine Quint wrote: > Before I ask on svg-dev, I was wondering if you knew how to use > addEventListener. I think this is the method I need, but I'm not sure. This would indeed be the right way to do it. I haven't tested it with ASV though. evtTarget.addEventListener( type, listener, boolCapture); Look into the DOM 2 Events, it's all explained (not too obscurely). -- _______________________________________________________________________ Robin Berjon <ro...@kn...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- An eye for an eye will make the whole world blind. -- Mahatma Gandhi |
|
From: Antoine Q. <an...@gr...> - 2001-09-17 13:49:51
|
Hey, Just though of a new use for getBBox(). For the "drag.es" module, an invisible rectangle is created to prevent unwanted "mouseout" events to happen. We could actually do with something smaller than the full-composition rectangle by just calling getBBox() on the dragged element and create an invisible rectangle that would be 110% the size of the bounding box. That would be cleaner I suppose. The invisible rectangle would have to be dragged though, but I don't reckon it's too much hassle. ---- And this is a little trick to prevent the Adobe contectual menu to appear on right-click. This is pretty pointless as is, but one could implement a completely new draggable-contextual menu on right click! This is going on graougraou.com's new site. function mouse_down(evt) { if(evt.getButton() == 2) { evt.preventDefault(); // right-click code } antoine |
|
From: Antoine Q. <an...@gr...> - 2001-09-17 08:14:46
|
Yo,
Before I ask on svg-dev, I was wondering if you knew how to use
addEventListener. I think this is the method I need, but I'm not sure.
What I want to do is to add function calls to "onmousemove" and such
events on SVG elements. Right now, I am using
element.setAttribute('onmousemove', 'my_sub(evt)'); which works but is a
pain when you already have a sub handling a "onmousemove" event on that
element (I guess it is just plainly overridden in this example).
So what I would want is a DOM method that just adds the new sub.
antoine
|
|
From: Robin B. <ro...@kn...> - 2001-09-16 21:32:25
|
On Sunday 16 September 2001 23:08, Antoine Quint wrote: > > Well as long as it's under control it's not much of a > > problem. Theoretically, > > severage.sf.net is best hosted elsewhere, so I guess that > > "elsewhere" is the > > best place. > > Well, sometime soon I think I'll create www.severage.org and its > namespace equivalent ns.severage.org and the likes. That would be best of course. > > It's not so much about me as it is about the world at large. > > People will not > > use settings that are not standard. What I listed above is > > part of what > > everyone uses when communicating at large in projects. > > But there are no "standard settings". People coding in different > languages use different settings. Still, there will be some, especially > for nestings, sub names and prefixes. Yes there are, the default settings used accross multiple languages (perhaps with the exception of Python but I very much doubt it) are 4 or 8 tabstops (people prefer 4 usually, that's now the most frequent default in editors) and no actual tabs (only spaces). Beyond that, the rest is pretty much language specific, but it's rather easy to find rules from other languages (eg C, Perl, etc) that would map prettu well to E262. > As for the documentation, I think all 3 options are valid and if the > effort of creating those 3 possibilities from the master > comment-document and modularized EcmaScript files is not too much of a > hefty task then we might as well offer all 3 for download on the site! It would indeed be trivial, and yes of course we should distribute all the packages. The devers will want the source with multiple small files and inline docs, users will want the doc in nice XML (transformed to XHTML+CSS I guess) and a single gzipped ball for lightweightedness. -- _______________________________________________________________________ Robin Berjon <ro...@kn...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- An eye for an eye will make the whole world blind. -- Mahatma Gandhi |
|
From: Antoine Q. <an...@gr...> - 2001-09-16 21:08:18
|
Hey, > Well as long as it's under control it's not much of a > problem. Theoretically, > severage.sf.net is best hosted elsewhere, so I guess that > "elsewhere" is the > best place. Well, sometime soon I think I'll create www.severage.org and its namespace equivalent ns.severage.org and the likes. > Ok, nevermind. The internal project here is called kestrel > because it sounds > like a cute little name for a windowing system, but who > cares. It's just that > people remember names better than acronyms. Yes, but they'll remember SVG already so that's just one more letter! But I don't think this is a big issue, if an issue at all. > It's not so much about me as it is about the world at large. > People will not > use settings that are not standard. What I listed above is > part of what > everyone uses when communicating at large in projects. But there are no "standard settings". People coding in different languages use different settings. Still, there will be some, especially for nestings, sub names and prefixes. As for the documentation, I think all 3 options are valid and if the effort of creating those 3 possibilities from the master comment-document and modularized EcmaScript files is not too much of a hefty task then we might as well offer all 3 for download on the site! antoine |
|
From: Robin B. <ro...@kn...> - 2001-09-16 20:57:26
|
On Sunday 16 September 2001 22:40, Antoine Quint wrote: > Ok, we'll have the namespace hosted somewhere else... I'm just not sure > where? On graougraou.com I guess... Well as long as it's under control it's not much of a problem. Theoretically, severage.sf.net is best hosted elsewhere, so I guess that "elsewhere" is the best place. > Well, it is just an acronym for what it is... I don't think we need > something fancy, iSVG is just a subproject anyway... Like XSP or XPS if > you will. Ok, nevermind. The internal project here is called kestrel because it sounds like a cute little name for a windowing system, but who cares. It's just that people remember names better than acronyms. > Hmm, I guess this is going to be pretty hard. I've been following > persistent guidelines on the most recent iSVG developments. But I'm not > sure you'll like all of them. It's not so much about me as it is about the world at large. People will not use settings that are not standard. What I listed above is part of what everyone uses when communicating at large in projects. > That's what I thought, I think I'll just email the svg-list about > this... that is only if I can sort out the awful stuff that's been going > on with my yahoo group account. I can post there myself. One thing that I'd be interested in knowing is if there's a way to add missing methods to Adobe's interface. I think there's something about that in E262, chapter the Object object. > There are comments already, but I don' think they would stand for > documentation purposes. I think the doc has to be seperated since the > script files have to be kept at the smallest weight. No, it really is best to include the doc inline. What Java does here (I'm thinking about that because it has a similar syntax) is that all comments that start with /** are documentation. We could use something like that, together with simplistic XML tags in those comments to give a touch of structure. If we don't do that it'll never be commented. Weight is not a problem, there'll be a pre-processor that'll generate a version with no embedded doc. We'll need a build preprocessor anyway if we want to stay sane. I think the best _usage_ format is to have the entire library in a single gzipped file, but the best dev format is probably to have a lot of smaller special purpose files. The build preprocessor would 1) put all the files into a single one, 2) extract all the doc, remove it from the source, and save it to a doc file, 3) gzip the es file for release. That'll make our lives a hell of a lot more easier, all that with a stupid 20 lines preprocessor. -- _______________________________________________________________________ Robin Berjon <ro...@kn...> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com ----------------------------------------------------------------------- An eye for an eye will make the whole world blind. -- Mahatma Gandhi |
|
From: Antoine Q. <an...@gr...> - 2001-09-16 20:40:34
|
Yo, This is the first post on the brand-spanking-new iSVG list! Switching to English now > > Oui, je vois ce que tu veux dire, en meme temps, c'est la > que le projet > > est hoste... Puis c'est assez neutre... > > C'est une tres mauvaise idee, SF a deja change plusieurs fois > son systeme de > nommage. Sans parler des projets qui disparaissent, etc... Ca > fout un peu en > l'air le principe de garantie d'unicite sans lequel ca ne > sert pas a grand > chose d'utiliser des ns. Ok, we'll have the namespace hosted somewhere else... I'm just not sure where? On graougraou.com I guess... > > > Et puis il faudrait trouver un > > > nom bien meilleur que iSVG, c'est un peu cheap. > > Tu trouves ca vraiment imaginatif, interessant, allechant, etc ? Well, it is just an acronym for what it is... I don't think we need something fancy, iSVG is just a subproject anyway... Like XSP or XPS if you will. > Il faut aussi des coding guidelines qui collent pour tous > (tabstops a 4, pas > de tabs purs, juste des spaces; positionnement des if, etc.). Hmm, I guess this is going to be pretty hard. I've been following persistent guidelines on the most recent iSVG developments. But I'm not sure you'll like all of them. > En theorie oui: svgSvgElement.createSVGPoint(x, y). > Malheureusement Adobe n'a > pas implemente ca encore (d'apres eux). A mon avis quand ca n'est pas > implemente par Adobe ca vaut le coup de les reimplementer, a > terme ca fera du > code plus clair. Tout ce qu'il faut pour SVGPoint par exemple c'est > get/setX/Y() et matrixTransform(). > Ce qu'il faudrait leur demander c'est quand est-ce qu'ils > vont implementer > tout ces petits details simples qui rendent la vie tellement > plus facile a > ceux qui veulent faire des scripts complexes. That's what I thought, I think I'll just email the svg-list about this... that is only if I can sort out the awful stuff that's been going on with my yahoo group account. > Il faut que la doc soit inclue dans le js (dans des comments > speciaux) et > qu'un petit preprocesseur puisse les extraire pour en faire > un doc XML. Sinon > ca sera jamais documente correctement. There are comments already, but I don' think they would stand for documentation purposes. I think the doc has to be seperated since the script files have to be kept at the smallest weight. antoine |
1 message has been excluded from this view by a project administrator.
