Et des onglets ! Un navigateur sans onglets c'est devenu has been ;)
Hum... le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant... si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte... ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets... ).
Pour le reste, je suis globalement d'accord avec toi.
[^] # Re: Euh... tu déconnes ?
Posté par freem . En réponse au message Pourquoi c'est dur de coder un navigateur Internet ?. Évalué à 1.
Hum... le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant... si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte... ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets... ).
Pour le reste, je suis globalement d'accord avec toi.