mon mini-toolkit de fenêtrage

whygee

11/02/2009 à 04:13

Grâce aux stimulantes suggestions de SAM,
http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:

Le 2/10/09 10:46 PM, whygee a écrit :
- pour le support MSIE, j'ajoute
var evt = e || window.event;
là où on utilise l'événement.

comme tu veux,
je n'ai pas vu de couac avec mon IE sans cela
(savoir si pos(ev) est déjà passé par là ou non ?)

certainement.
d'ailleurs au final, pos() a remplacé presque tout.

- je viens à peine de comprendre à quoi sert pos(ev) :-)

c'est pour tenter d'avoir pageX et pageY avec IE
Mais à tous coups ça ne sert à rien et clientX clientY auraient f ait le
taf pour tt le monde.
(QM se sert de ces clients là pour son DnD)

bah... au pire on change la fonction, mais bon, ça a l'air solide...

- ygwm.showhide() est un sacré exemple de compression du code,
bien que j'ai peur que ce soit moins fiable si un élément
était désynchronisé... donc je garde l'ancien code ;-)

comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appel les
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

solution : tester l'attribut "display" au lieu du className.

Tiens ? puisque tu captes tt de suite le parent, pourquoi n'aurai-il pa s
lui le maxi/mini ?
ainsi on fait l'économie de this et des display des contents et foote r

ygwm.showhide= function(ev) { // à quoi sert ce ev qu'on balade par tout?
var parent = ygwm.getParent(this);
parent.className = parent.className.indexOf('maximize')>=0?
parent.className.replace('maximize','minimize') :
parent.className.replace('minimize','maximize');
}

J'ai choisi une méthode différente : 1 seule classe par élément,
mais utilisant la CSS pour combiner les propriétés.
en jouant sur les valeurs par défaut et autres héritages surécrits,
j'ai pu faire du code plus compact en CSS ET JS.

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

ainsi on a pour le header :
div.ygwm_header,
div.ygwm_selected {
/// tout le bazar
background-color: #CCC;
}
div.ygwm_selected {
background-color: #AAA;
}

donc on change la couleur quand le focus est dessus.
ça se complique à cause du background du "bouton"
mini/maximize... La solution vient de la spec CSS2
qui permet de sélectionner un élément en fonction de
son parent :

// version normale
div.ygwm_corner_maximize {
border-color: #CCC #CCC #888 #CCC;
}
// version avec sélection
div.ygwm_selected > div.ygwm_corner_maximize {
border-color: #AAA #AAA #777 #AAA;
}

la classe ygwm_corner a été mergée avec tout le monde :

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

- " +' <div class="ygwm_msg"></div>'"
j'avais pas remarqué de problème sans le "",
ça a posé problème quelque part ?

Ça risque de ne pas plaire, le '<' en JS pose parfois pb tands que le
'>', non (ne pas me demander pourquoi, ça date du siècle dernier)
En tous cas dans le view-source de Fx, manifestement ça ne plait pas.

faudrait voir ce que dit le standard ECMA...

- il semble y avoir une incohérence, avec offsetWidth,
offsetLeft et offsetHeight, j'ai pas bien compris
pourquoi des variables ont été ajoutées et utilisées
mais sans être initialisées... à moins que ça fasse
partie du DOM ?

oui ce sont des propriétés des éléments (alors pourquoi les sto cker ?)

à l'époque je ne savais pas comment me débrouiller.
il semble donc que la valeur soit stockée ET inscriptible
selon 2 formats. Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'
maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

Il n'y a que offsetHeight qui m'em...e
je n'arrive pas à voir quand le div (et lequel) récupère div_heig ht
ni exactement quand on en a besoin pour le redimensionnement.

"chez moi ça marche" du premier coup...
A tester sur
http://yasep.org/~whygee/ygwm/ygwm.html

<http://www.quirksmode.org/js/events_properties.html#position>
un peu + abouti que mon pos(ev) !
Mébon ... c'est du délayage à la Pascal.

c'est très bien Pascal, et d'ailleurs
ce langage a été conçu pour compiler à très grande vitesse...
et c'est libible :-)

ça a dû être une sacrée histoire de faire toutes ces modifica tions :-)

Un peu :-)
(déjà arriver à suivre le serpent qui s'entortille ...)

je n'en doute pas...
c'est pour ça aussi que j'essaie de garder ygwm compact...
et de ne pas céder à l'appel de la "fonctionalite" :-)
moins on en fait, plus c'est solide.

En attendant de tout reprendre avec un listener général qui pourra
s'occuper de chaque pipeau ou trou de pipeau sans plus de
duplication/multiplication de tous les trucs stockés lors des
new new_window(bla bla);

pour l'instant je trouve que c'est déjà pas si mal :-)

Allez, j'ajoute une dernière fonctionalité et je vais dormir ;-)
si on ne met pas le header ni le footer, ça devient presque une
fenêtre d'alert...

--
http://ygdes.com / http://yasep.org

Grâce aux stimulantes suggestions de SAM,
http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:

Le 2/10/09 10:46 PM, whygee a écrit :

- pour le support MSIE, j'ajoute
var evt = e || window.event;
là où on utilise l'événement.

comme tu veux,
je n'ai pas vu de couac avec mon IE sans cela
(savoir si pos(ev) est déjà passé par là ou non ?)

certainement.
d'ailleurs au final, pos() a remplacé presque tout.

- je viens à peine de comprendre à quoi sert pos(ev) :-)

c'est pour tenter d'avoir pageX et pageY avec IE
Mais à tous coups ça ne sert à rien et clientX clientY auraient f ait le
taf pour tt le monde.
(QM se sert de ces clients là pour son DnD)

bah... au pire on change la fonction, mais bon, ça a l'air solide...

- ygwm.showhide() est un sacré exemple de compression du code,
bien que j'ai peur que ce soit moins fiable si un élément
était désynchronisé... donc je garde l'ancien code ;-)

comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appel les
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

solution : tester l'attribut "display" au lieu du className.

Tiens ? puisque tu captes tt de suite le parent, pourquoi n'aurai-il pa s
lui le maxi/mini ?
ainsi on fait l'économie de this et des display des contents et foote r

ygwm.showhide= function(ev) { // à quoi sert ce ev qu'on balade par tout?
var parent = ygwm.getParent(this);
parent.className = parent.className.indexOf('maximize')>=0?
parent.className.replace('maximize','minimize') :
parent.className.replace('minimize','maximize');
}

J'ai choisi une méthode différente : 1 seule classe par élément,
mais utilisant la CSS pour combiner les propriétés.
en jouant sur les valeurs par défaut et autres héritages surécrits,
j'ai pu faire du code plus compact en CSS ET JS.

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

ainsi on a pour le header :
div.ygwm_header,
div.ygwm_selected {
/// tout le bazar
background-color: #CCC;
}
div.ygwm_selected {
background-color: #AAA;
}

donc on change la couleur quand le focus est dessus.
ça se complique à cause du background du "bouton"
mini/maximize... La solution vient de la spec CSS2
qui permet de sélectionner un élément en fonction de
son parent :

// version normale
div.ygwm_corner_maximize {
border-color: #CCC #CCC #888 #CCC;
}
// version avec sélection
div.ygwm_selected > div.ygwm_corner_maximize {
border-color: #AAA #AAA #777 #AAA;
}

la classe ygwm_corner a été mergée avec tout le monde :

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

- " +' <div class="ygwm_msg"></div>'"
j'avais pas remarqué de problème sans le "",
ça a posé problème quelque part ?

Ça risque de ne pas plaire, le '<' en JS pose parfois pb tands que le
'>', non (ne pas me demander pourquoi, ça date du siècle dernier)
En tous cas dans le view-source de Fx, manifestement ça ne plait pas.

faudrait voir ce que dit le standard ECMA...

- il semble y avoir une incohérence, avec offsetWidth,
offsetLeft et offsetHeight, j'ai pas bien compris
pourquoi des variables ont été ajoutées et utilisées
mais sans être initialisées... à moins que ça fasse
partie du DOM ?

oui ce sont des propriétés des éléments (alors pourquoi les sto cker ?)

à l'époque je ne savais pas comment me débrouiller.
il semble donc que la valeur soit stockée ET inscriptible
selon 2 formats. Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'
maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

Il n'y a que offsetHeight qui m'em...e
je n'arrive pas à voir quand le div (et lequel) récupère div_heig ht
ni exactement quand on en a besoin pour le redimensionnement.

"chez moi ça marche" du premier coup...
A tester sur
http://yasep.org/~whygee/ygwm/ygwm.html

<http://www.quirksmode.org/js/events_properties.html#position>
un peu + abouti que mon pos(ev) !
Mébon ... c'est du délayage à la Pascal.

c'est très bien Pascal, et d'ailleurs
ce langage a été conçu pour compiler à très grande vitesse...
et c'est libible :-)

ça a dû être une sacrée histoire de faire toutes ces modifica tions :-)

Un peu :-)
(déjà arriver à suivre le serpent qui s'entortille ...)

je n'en doute pas...
c'est pour ça aussi que j'essaie de garder ygwm compact...
et de ne pas céder à l'appel de la "fonctionalite" :-)
moins on en fait, plus c'est solide.

En attendant de tout reprendre avec un listener général qui pourra
s'occuper de chaque pipeau ou trou de pipeau sans plus de
duplication/multiplication de tous les trucs stockés lors des
new new_window(bla bla);

pour l'instant je trouve que c'est déjà pas si mal :-)

Allez, j'ajoute une dernière fonctionalité et je vais dormir ;-)
si on ne met pas le header ni le footer, ça devient presque une
fenêtre d'alert...

--
http://ygdes.com / http://yasep.org

Vous avez filtré cet utilisateur ! Consultez son message

Grâce aux stimulantes suggestions de SAM,
http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:

Le 2/10/09 10:46 PM, whygee a écrit :
- pour le support MSIE, j'ajoute
var evt = e || window.event;
là où on utilise l'événement.

comme tu veux,
je n'ai pas vu de couac avec mon IE sans cela
(savoir si pos(ev) est déjà passé par là ou non ?)

certainement.
d'ailleurs au final, pos() a remplacé presque tout.

- je viens à peine de comprendre à quoi sert pos(ev) :-)

c'est pour tenter d'avoir pageX et pageY avec IE
Mais à tous coups ça ne sert à rien et clientX clientY auraient f ait le
taf pour tt le monde.
(QM se sert de ces clients là pour son DnD)

bah... au pire on change la fonction, mais bon, ça a l'air solide...

- ygwm.showhide() est un sacré exemple de compression du code,
bien que j'ai peur que ce soit moins fiable si un élément
était désynchronisé... donc je garde l'ancien code ;-)

comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appel les
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

solution : tester l'attribut "display" au lieu du className.

Tiens ? puisque tu captes tt de suite le parent, pourquoi n'aurai-il pa s
lui le maxi/mini ?
ainsi on fait l'économie de this et des display des contents et foote r

ygwm.showhide= function(ev) { // à quoi sert ce ev qu'on balade par tout?
var parent = ygwm.getParent(this);
parent.className = parent.className.indexOf('maximize')>=0?
parent.className.replace('maximize','minimize') :
parent.className.replace('minimize','maximize');
}

J'ai choisi une méthode différente : 1 seule classe par élément,
mais utilisant la CSS pour combiner les propriétés.
en jouant sur les valeurs par défaut et autres héritages surécrits,
j'ai pu faire du code plus compact en CSS ET JS.

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

ainsi on a pour le header :
div.ygwm_header,
div.ygwm_selected {
/// tout le bazar
background-color: #CCC;
}
div.ygwm_selected {
background-color: #AAA;
}

donc on change la couleur quand le focus est dessus.
ça se complique à cause du background du "bouton"
mini/maximize... La solution vient de la spec CSS2
qui permet de sélectionner un élément en fonction de
son parent :

// version normale
div.ygwm_corner_maximize {
border-color: #CCC #CCC #888 #CCC;
}
// version avec sélection
div.ygwm_selected > div.ygwm_corner_maximize {
border-color: #AAA #AAA #777 #AAA;
}

la classe ygwm_corner a été mergée avec tout le monde :

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

- " +' <div class="ygwm_msg"></div>'"
j'avais pas remarqué de problème sans le "",
ça a posé problème quelque part ?

Ça risque de ne pas plaire, le '<' en JS pose parfois pb tands que le
'>', non (ne pas me demander pourquoi, ça date du siècle dernier)
En tous cas dans le view-source de Fx, manifestement ça ne plait pas.

faudrait voir ce que dit le standard ECMA...

- il semble y avoir une incohérence, avec offsetWidth,
offsetLeft et offsetHeight, j'ai pas bien compris
pourquoi des variables ont été ajoutées et utilisées
mais sans être initialisées... à moins que ça fasse
partie du DOM ?

oui ce sont des propriétés des éléments (alors pourquoi les sto cker ?)

à l'époque je ne savais pas comment me débrouiller.
il semble donc que la valeur soit stockée ET inscriptible
selon 2 formats. Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'
maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

Il n'y a que offsetHeight qui m'em...e
je n'arrive pas à voir quand le div (et lequel) récupère div_heig ht
ni exactement quand on en a besoin pour le redimensionnement.

"chez moi ça marche" du premier coup...
A tester sur
http://yasep.org/~whygee/ygwm/ygwm.html

<http://www.quirksmode.org/js/events_properties.html#position>
un peu + abouti que mon pos(ev) !
Mébon ... c'est du délayage à la Pascal.

c'est très bien Pascal, et d'ailleurs
ce langage a été conçu pour compiler à très grande vitesse...
et c'est libible :-)

ça a dû être une sacrée histoire de faire toutes ces modifica tions :-)

Un peu :-)
(déjà arriver à suivre le serpent qui s'entortille ...)

je n'en doute pas...
c'est pour ça aussi que j'essaie de garder ygwm compact...
et de ne pas céder à l'appel de la "fonctionalite" :-)
moins on en fait, plus c'est solide.

En attendant de tout reprendre avec un listener général qui pourra
s'occuper de chaque pipeau ou trou de pipeau sans plus de
duplication/multiplication de tous les trucs stockés lors des
new new_window(bla bla);

pour l'instant je trouve que c'est déjà pas si mal :-)

Allez, j'ajoute une dernière fonctionalité et je vais dormir ;-)
si on ne met pas le header ni le footer, ça devient presque une
fenêtre d'alert...

--
http://ygdes.com / http://yasep.org

whygee

11/02/2009 à 05:36

Bon c'est tout pour cette nuit :-)
le code a énormément bougé,
heureusement qu'il reste encore petit :-)

Aussi, j'ai remarqué à propos du code suivant :

<p><a href="javascript:alert('vu')" onContextMenu="return false">lien sans menu contectuel</a> fonctionne aussi avec IE</p>
<p><a href="javascript:alert('vu')">lien acceptant le menu contectuel</ a></p>

j'ai pas vraiment de différence, puisqu'il s'agit d'un <a href>,
alors que le coup du onclick+CTRL est sur un div ou un <td>...
mais ça c'est pour listed, pas ygwm.

d'ailleurs je trouve que listed est 2x mieux qu'il y a 2 jours :-)

enjoy,
yg

--
http://ygdes.com / http://yasep.org

SAM

12/02/2009 à 01:06

Le 2/11/09 4:13 AM, whygee a écrit :

Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:
comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appelles
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

Ha? ce n'est que ça ?
Faut dire qu'avec ton ténia c'est facile ;-)
J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

à propos de focus, je pense que c'est ça qui merdouille avec IE.
Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on chope
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélectionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre de
devant.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

C'est surtout que c'était facile :
une ligne à écrire pour un tronçon du ténia

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

oui ce sont des propriétés des éléments (alors pourquoi les stocker ?)

à l'époque je ne savais pas comment me débrouiller.

(...)

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

--
sm

Le 2/11/09 4:13 AM, whygee a écrit :

Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:

comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appelles
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

Ha? ce n'est que ça ?
Faut dire qu'avec ton ténia c'est facile ;-)
J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

à propos de focus, je pense que c'est ça qui merdouille avec IE.
Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on chope
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélectionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre de
devant.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

C'est surtout que c'était facile :
une ligne à écrire pour un tronçon du ténia

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

oui ce sont des propriétés des éléments (alors pourquoi les stocker ?)

à l'époque je ne savais pas comment me débrouiller.

(...)

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Le 2/11/09 4:13 AM, whygee a écrit :

Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

http://yasep.org/~whygee/ygwm/ygwm.html
est à jour avec des techniques plus robustes !

SAM wrote:
comme j'ai perdu l'ancien code dans les oubliettes de mon DD ...
Je ne vois pas comment ça peut se désynchroniser puisque tu y appelles
le parent pour lui demander où il en est.

pour se désynchroniser, c'est simple : il suffit de bricoler un fichier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :-)

Ha? ce n'est que ça ?
Faut dire qu'avec ton ténia c'est facile ;-)
J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

Avec en prime l'ajout d'un stule "focus" pour voir quelle fenêtre
est en cours d'utilisation :-)

à propos de focus, je pense que c'est ça qui merdouille avec IE.
Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on chope
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélectionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre de
devant.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

div.ygwm_cornerSW,
div.ygwm_cornerSE,
div.ygwm_corner_minimize,
div.ygwm_corner_maximize {
border: 10px solid;
width: 0px;
height: 0px;
float: right;
cursor: pointer;
}

merci la CSS !

Et changer un peu la CSS et qques bricoles :
<http://cjoint.com/data/cna0SSzlBu_ygwm_sam_iso_1.html>
Je me suis ajouté mon double-clic, na!

arf :-)
en tout cas, ravi que ça ait procuré un peu d'amusement :-)

C'est surtout que c'était facile :
une ligne à écrire pour un tronçon du ténia

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

oui ce sont des propriétés des éléments (alors pourquoi les stocker ?)

à l'époque je ne savais pas comment me débrouiller.

(...)

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

maintenant que j'ai vu ça, j'ai fait le nettoyage de
ces variables superflues.

--
sm

SAM

12/02/2009 à 01:17

Le 2/11/09 5:36 AM, whygee a écrit :

Bon c'est tout pour cette nuit :-)
le code a énormément bougé,
heureusement qu'il reste encore petit :-)

Aussi, j'ai remarqué à propos du code suivant :

<p><a href="javascript:alert('vu')" onContextMenu="return false">lien
sans menu contectuel</a> fonctionne aussi avec IE</p>
<p><a href="javascript:alert('vu')">lien acceptant le menu
contectuel</a></p>

j'ai pas vraiment de différence, puisqu'il s'agit d'un <a href>,
alors que le coup du onclick+CTRL est sur un div ou un <td>...
mais ça c'est pour listed, pas ygwm.

Alors ... comment fonctionne le menu-contextuel :
- il fonctionne *partout* dans la fenêtre
- Il change suivant le "contexte"
suivant l'élément sur lequel le clic-droit est appliqué
- image [afficher même fen ou autre onglet, enregistrer]
- lien [afficher ici ou là, copier, enregistrer]
- cadre (frame, iframe)
- ...
- élément non répertorié : [enregistrer page, etc...]

d'ailleurs je trouve que listed est 2x mieux qu'il y a 2 jours :-)

Il est hatchement mieux dans iCab ou Safari :
les pipeaux gavés de tables y ont un mouvement très fluide au drag.

--
sm

whygee

12/02/2009 à 01:23

_o/ bonsoir !

Je viens de mettre en ligne une version toute fraiche,
qui corrige un bug qu'un copain a trouvé avec Chrome.
Je me concentre sur listed en ce moment.

SAM wrote:

Le 2/11/09 4:13 AM, whygee a écrit :
Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

:-)

SAM wrote:
pour se désynchroniser, c'est simple : il suffit de bricoler un fich ier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :- )

Ha? ce n'est que ça ?

ben faut que ce soit foolproof,
si un truc était modifié mais un détail est oublié dans
le reste du code, faut pas que ça plante ou que ça se vautre...

J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

ben à ma connaissance non mais on n'est jamais à l'abri des bugs.
et j'essaie d'éviter l'avalanche...

à propos de focus, je pense que c'est ça qui merdouille avec IE.

il n'aime pas la fonction focus_window
qui est attachée au DIV principal par
new_id.onmousedown=ygwm.focus_window;
?

Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on cho pe
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélec tionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre d e devant.

il faudrait explorer la piste du bubbling...
peut-être que la fonction focus_window
ne retourne pas la bonne valeur ?
voir le commentaire à la fin du focus_window, dans le if :
faut-il renvoyer true ou false ?
je vais te laisser essayer.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

en tout cas c'en est une qui me plait car elle réduit la taille
du CSS et évite d'avoir des classes multiples à gérer.
d'ailleurs j'ai modifié getElement en conséquence,
je teste l'égalité de chaine au lieu de chercher une sous-chaine.

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

c'est pas pris sous FF...
avec bouton droit alors ?
mais ça va déclencher le menu :-/

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

voilà.
ben je savais pas ça il y a encore 2 jours...

bon, recharge ygwm, je viens de le modifier à l'instant.
http://yasep.org/~whygee/ygwm/

--
http://ygdes.com / http://yasep.org

_o/ bonsoir !

Je viens de mettre en ligne une version toute fraiche,
qui corrige un bug qu'un copain a trouvé avec Chrome.
Je me concentre sur listed en ce moment.

SAM wrote:

Le 2/11/09 4:13 AM, whygee a écrit :

Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

:-)

SAM wrote:
pour se désynchroniser, c'est simple : il suffit de bricoler un fich ier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :- )

Ha? ce n'est que ça ?

ben faut que ce soit foolproof,
si un truc était modifié mais un détail est oublié dans
le reste du code, faut pas que ça plante ou que ça se vautre...

J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

ben à ma connaissance non mais on n'est jamais à l'abri des bugs.
et j'essaie d'éviter l'avalanche...

à propos de focus, je pense que c'est ça qui merdouille avec IE.

il n'aime pas la fonction focus_window
qui est attachée au DIV principal par
new_id.onmousedown=ygwm.focus_window;
?

Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on cho pe
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélec tionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre d e devant.

il faudrait explorer la piste du bubbling...
peut-être que la fonction focus_window
ne retourne pas la bonne valeur ?
voir le commentaire à la fin du focus_window, dans le if :
faut-il renvoyer true ou false ?
je vais te laisser essayer.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

en tout cas c'en est une qui me plait car elle réduit la taille
du CSS et évite d'avoir des classes multiples à gérer.
d'ailleurs j'ai modifié getElement en conséquence,
je teste l'égalité de chaine au lieu de chercher une sous-chaine.

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

c'est pas pris sous FF...
avec bouton droit alors ?
mais ça va déclencher le menu :-/

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

voilà.
ben je savais pas ça il y a encore 2 jours...

bon, recharge ygwm, je viens de le modifier à l'instant.
http://yasep.org/~whygee/ygwm/

--
http://ygdes.com / http://yasep.org

Vous avez filtré cet utilisateur ! Consultez son message

_o/ bonsoir !

Je viens de mettre en ligne une version toute fraiche,
qui corrige un bug qu'un copain a trouvé avec Chrome.
Je me concentre sur listed en ce moment.

SAM wrote:

Le 2/11/09 4:13 AM, whygee a écrit :
Grâce aux stimulantes suggestions de SAM,

Ha! ça! je m'y entends pour titiller ;-)

:-)

SAM wrote:
pour se désynchroniser, c'est simple : il suffit de bricoler un fich ier
ou une fonction. Par exemple, modifier le nom d'une classe, ou la CSS,
et "pan!" ça marche plus. ça m'est arrivé justement il y a 1h :- )

Ha? ce n'est que ça ?

ben faut que ce soit foolproof,
si un truc était modifié mais un détail est oublié dans
le reste du code, faut pas que ça plante ou que ça se vautre...

J'avais compris que les éléments se désynchronisent tous seuls.
(a force de les bouger, créer, étoussa)

ben à ma connaissance non mais on n'est jamais à l'abri des bugs.
et j'essaie d'éviter l'avalanche...

à propos de focus, je pense que c'est ça qui merdouille avec IE.

il n'aime pas la fonction focus_window
qui est attachée au DIV principal par
new_id.onmousedown=ygwm.focus_window;
?

Il me semble que tu as qque part un truc mousedown pour choper le
pipeau. (rappel : pipeau = fause-fenêtre du bignou)
Tant qu'on chope une fenêtre d'arrière-plan ça va, mais si on cho pe
celle d'avant-plan c'est là qu'IE, lors du drag, commence à sélec tionner
les textes éparpillés un peu partout.
Il faudrait trouver un contre-truc pour le mousedown sur la fenêtre d e devant.

il faudrait explorer la piste du bubbling...
peut-être que la fonction focus_window
ne retourne pas la bonne valeur ?
voir le commentaire à la fin du focus_window, dans le if :
faut-il renvoyer true ou false ?
je vais te laisser essayer.

la classe ygwm_corner a été mergée avec tout le monde :

Oui ce peut être une soluce (si on abandonne les multi-class)

en tout cas c'en est une qui me plait car elle réduit la taille
du CSS et évite d'avoir des classes multiples à gérer.
d'ailleurs j'ai modifié getElement en conséquence,
je teste l'égalité de chaine au lieu de chercher une sous-chaine.

tiens d'ailleurs le double-click, c'est une bonne idée
pour éditer le nom de la fenêtre...

Ha! non ! C'est déjà pris et righté.
Trouve ot' chose.

c'est pas pris sous FF...
avec bouton droit alors ?
mais ça va déclencher le menu :-/

Par contre :
- faut lire avec E.offsetXxxxx
- écrire avec E.style.XXX=x+'px'

B.style.width = A.offsetWidth + 'px';

voilà.
ben je savais pas ça il y a encore 2 jours...

bon, recharge ygwm, je viens de le modifier à l'instant.
http://yasep.org/~whygee/ygwm/

--
http://ygdes.com / http://yasep.org

whygee

12/02/2009 à 01:28

SAM wrote:

Le 2/11/09 5:36 AM, whygee a écrit :
d'ailleurs je trouve que listed est 2x mieux qu'il y a 2 jours :-)

Il est hatchement mieux dans iCab ou Safari :
les pipeaux gavés de tables y ont un mouvement très fluide au drag.

c'est bien possible.
c'est vrai que sur mon vieux P3 avec debian/FF3, je sens qu'il fait un ef fort...
mais sérieusement, si j'avais voulu un truc rapide, j'aurais fait le
programme avec la Xlib pour Unix. Mais j'ai déjà donné...
la rapidité d'exécution est inversement proportionnelle
à la vitesse de développement, et j'ai envie d'arriver quelque part u n jour :-)
Donc pas grave si c'est un peu lent, j'essaie de garder mes algos
en O(n) ou O(1) autant que nécessaires, et c'est bon...

--
http://ygdes.com / http://yasep.org

whygee

12/02/2009 à 01:46

SAM wrote:

Le 2/12/09 1:28 AM, whygee a écrit :
Donc pas grave si c'est un peu lent, j'essaie de garder mes algos
en O(n) ou O(1) autant que nécessaires, et c'est bon...

et en enlevant le contenu lors du drag ?
(enlever/remettre les éléments avec l'aide d'un array se fait à v itesse
éclair)
genre draguer une fenêtre fantôme puis déplacer au drop

j'y avais pensé mais ça rajouterait du code,
et aussi ce n'est pas un truc critique :
on ne passe pas son temps à déplacer les fenêtres :-)

ou sinon, un simple
ygwm.moved_div.contents_id.firstChild.style.display="none";
ne suffirait pas ?

--
http://ygdes.com / http://yasep.org

SAM

12/02/2009 à 01:58

Le 2/12/09 1:28 AM, whygee a écrit :

Donc pas grave si c'est un peu lent, j'essaie de garder mes algos
en O(n) ou O(1) autant que nécessaires, et c'est bon...

et en enlevant le contenu lors du drag ?
(enlever/remettre les éléments avec l'aide d'un array se fait à vitesse
éclair)
genre draguer une fenêtre fantôme puis déplacer au drop

--
sm

whygee

12/02/2009 à 02:17

SAM wrote:

Le 2/12/09 1:28 AM, whygee a écrit :
Donc pas grave si c'est un peu lent, j'essaie de garder mes algos
en O(n) ou O(1) autant que nécessaires, et c'est bon...

et en enlevant le contenu lors du drag ?
(enlever/remettre les éléments avec l'aide d'un array se fait à v itesse éclair)
genre draguer une fenêtre fantôme puis déplacer au drop

bon j'ai essayé de ne pas afficher le contenu
lors des déplacements, ça fait un peu bizarre
et le gain de vitesse n'est pas convaincant,
bien que ce soit peut-être accéléré de 2x.

J'ai bien l'impression que le reste du temps
perdu est au niveau de l'affichage lui-même,
c'est à dire le nombre de pixels à gérer,
en plus de leur valeur.

donc je "minimise" la fenêtre lors du déplacement :

mouse_drop : function (ev) {
...
ygwm.moved_div.contents_id.style.display="";

hook_move : function(ev) {
...
w.contents_id.style.display="none";

et là, c'est beaucoup plus fluide, mais moins
graphiquement intéressant.
On peut éventuellement conditionner celà à
une variable définie par l'utilisateur, genre
if (slowDisplay)
// minimize

Il faut voir aussi que le resize aussi est important,
et on ne peut pas minimiser durant cette opération.

bon, j'ajoute un bouton à cocher pour tester le mode "display:none",
sur listed.html et ygwm.html

--
http://ygdes.com / http://yasep.org

whygee

12/02/2009 à 03:13

whygee wrote:

bon, j'ajoute un bouton à cocher pour tester le mode "display:none",
sur listed.html et ygwm.html

bon, il se trouve qu'avec listed, quand on ajoute plein plein de lignes
au tableau, l'affichage met effectivement ... du temps.

bon, d'un côté, l'affichage n'est pas critique, et en plus
sur un PC bien récent, on ne sent pas vraiment de différence.

d'un autre côté, ça peut devenir très lent et une grosse
différence apparait lorsqu'on désactive l'affichage lors
des mouvements et resize.

dans un cas comme ça où chaque côté a des avantages et des
inconvénients, le mieux est d'avoir une solution médiane,
où le script détecte lorsque ça rame. Donc il doit mesurer
combien de temps met le rafraichissement, ou mieux,
si plusieurs demandes de rafraichissement sont en attente,
pour sauter les précédentes. A ce moment-là il peut décider
d'effacer le contenu, pour ne le restaurer qu'à la fin...

J'ai cru apercevoir sous FF que les événements souris
avaient un "timecode". ça pourrait être utile, ainsi
que des setTimeout bien placés et des variables-sémaphores...

vive le code adaptatif :-)

--
http://ygdes.com / http://yasep.org

mon mini-toolkit de fenêtrage

10 réponses

Veuillez sélectionner un problème