Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Je me permet de relancer ce poste.
En effet la classe Desktop est pratique pour afficher l'explorateur de
fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop
().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève
une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour
résoudre ce comportement, je suis preneur.
Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
jlp
Francis JUGE-BOIRARD a écrit :
Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb : ne peux-tu pas utiliser ProcessBuilder("command").start(); ? La "command" à adapter par rapport à la variable d'environnement os.name ( Linux, XP, AIX, Solaris, HP-UX ...)
Francis JUGE-BOIRARD a écrit :
Je me permet de relancer ce poste.
En effet la classe Desktop est pratique pour afficher l'explorateur de
fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop
().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève
une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour
résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb :
ne peux-tu pas utiliser ProcessBuilder("command").start(); ?
La "command" à adapter par rapport à la variable d'environnement os.name
( Linux, XP, AIX, Solaris, HP-UX ...)
Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb : ne peux-tu pas utiliser ProcessBuilder("command").start(); ? La "command" à adapter par rapport à la variable d'environnement os.name ( Linux, XP, AIX, Solaris, HP-UX ...)
jlp
jlp a écrit :
Francis JUGE-BOIRARD a écrit :
Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb : ne peux-tu pas utiliser ProcessBuilder("command").start(); ? La "command" à adapter par rapport à la variable d'environnement os.name ( Linux, XP, AIX, Solaris, HP-UX ...)
ou en pur java => JFileChooser
jlp a écrit :
Francis JUGE-BOIRARD a écrit :
Je me permet de relancer ce poste.
En effet la classe Desktop est pratique pour afficher l'explorateur de
fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop
().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève
une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour
résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb :
ne peux-tu pas utiliser ProcessBuilder("command").start(); ?
La "command" à adapter par rapport à la variable d'environnement os.name
( Linux, XP, AIX, Solaris, HP-UX ...)
Je me permet de relancer ce poste. En effet la classe Desktop est pratique pour afficher l'explorateur de fichier. Il ne s'agira dans ce contexte pas de Desktop.getDesktop ().open (File f) mais plustot de Desktop.getDesktop ().browse (URI u).
Ceci fonctionne parfaitement sur mon système sous windows XP mais lève une IOException sous linux (Fedora 11). Si quelqu'un à une piste pour résoudre ce comportement, je suis preneur.
Francis JUGE-BOIRARD
Peut-être hors contexte par rapport à ton pb : ne peux-tu pas utiliser ProcessBuilder("command").start(); ? La "command" à adapter par rapport à la variable d'environnement os.name ( Linux, XP, AIX, Solaris, HP-UX ...)
ou en pur java => JFileChooser
Francis JUGE-BOIRARD
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me chagrine est le fait que
sous windows XP : Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne correctement.
sous linux (Fedora 11) Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de l'utilisateur indépendamment de la plate-forme. C'est génial dans la mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé) retrouve son environnement de travail inchangé quel que soit la plate-f orme. L'usage d'un JFileChooser ne répond pas au cahier des charges de mon application et l'usage de start est clairement une manuvre de contournement d'un comportement anormal. De plus il existe un risque suivant la distribution de Linux utilisé de ne pas retrouver exactement la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est impossible de parcourir le répertoire automatiquement et je l'invite à le faire manuellement. C'est dommage et je me demande comment corriger cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec
de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me
chagrine est le fait que
sous windows XP :
Desktop.isSupported () == true
Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true
Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne
correctement.
sous linux (Fedora 11)
Desktop.isSupported () == true
Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true
Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une
IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de
l'utilisateur indépendamment de la plate-forme. C'est génial dans la
mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé)
retrouve son environnement de travail inchangé quel que soit la plate-f orme.
L'usage d'un JFileChooser ne répond pas au cahier des charges de mon
application et l'usage de start est clairement une manuvre de
contournement d'un comportement anormal. De plus il existe un risque
suivant la distribution de Linux utilisé de ne pas retrouver exactement
la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est
impossible de parcourir le répertoire automatiquement et je l'invite à
le faire manuellement. C'est dommage et je me demande comment corriger
cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me chagrine est le fait que
sous windows XP : Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne correctement.
sous linux (Fedora 11) Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de l'utilisateur indépendamment de la plate-forme. C'est génial dans la mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé) retrouve son environnement de travail inchangé quel que soit la plate-f orme. L'usage d'un JFileChooser ne répond pas au cahier des charges de mon application et l'usage de start est clairement une manuvre de contournement d'un comportement anormal. De plus il existe un risque suivant la distribution de Linux utilisé de ne pas retrouver exactement la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est impossible de parcourir le répertoire automatiquement et je l'invite à le faire manuellement. C'est dommage et je me demande comment corriger cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Xavier Nayrac
Francis JUGE-BOIRARD a écrit :
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me chagrine est le fait que
sous windows XP : Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne correctement.
sous linux (Fedora 11) Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de l'utilisateur indépendamment de la plate-forme. C'est génial dans la mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé) retrouve son environnement de travail inchangé quel que soit la plate-forme. L'usage d'un JFileChooser ne répond pas au cahier des charges de mon application et l'usage de start est clairement une manœuvre de contournement d'un comportement anormal. De plus il existe un risque suivant la distribution de Linux utilisé de ne pas retrouver exactement la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est impossible de parcourir le répertoire automatiquement et je l'invite à le faire manuellement. C'est dommage et je me demande comment corriger cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Bonjour, En lisant ton post original, je me suis dit "Tiens, pourquoi j'ai jamais pensé à ouvrir l'explorer comme çà ?". Alors j'ai essayé et comme toi : Sous Vista : ok Sous Ubuntu : IOException
Puis j'ai joué un peu avec les URI et j'ai trouvé le truc. Ca fonctionne avec Ubuntu, à toi de me dire si c'est pareil avec Fedora :
public class Main { public static void main(String[] args) { try { try { Desktop.getDesktop().browse(new URI("file:///home/xavier/Public")); } catch (IOException ex) { // ... } } catch (URISyntaxException ex) { // ... } } }
Sous Windows, il faut par exemple : new URI("file:///D:/test")
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec
de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me
chagrine est le fait que
sous windows XP :
Desktop.isSupported () == true
Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true
Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne
correctement.
sous linux (Fedora 11)
Desktop.isSupported () == true
Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true
Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une
IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de
l'utilisateur indépendamment de la plate-forme. C'est génial dans la
mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé)
retrouve son environnement de travail inchangé quel que soit la
plate-forme.
L'usage d'un JFileChooser ne répond pas au cahier des charges de mon
application et l'usage de start est clairement une manœuvre de
contournement d'un comportement anormal. De plus il existe un risque
suivant la distribution de Linux utilisé de ne pas retrouver exactement
la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est
impossible de parcourir le répertoire automatiquement et je l'invite à
le faire manuellement. C'est dommage et je me demande comment corriger
cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Bonjour,
En lisant ton post original, je me suis dit "Tiens, pourquoi j'ai jamais
pensé à ouvrir l'explorer comme çà ?".
Alors j'ai essayé et comme toi :
Sous Vista : ok
Sous Ubuntu : IOException
Puis j'ai joué un peu avec les URI et j'ai trouvé le truc. Ca fonctionne
avec Ubuntu, à toi de me dire si c'est pareil avec Fedora :
public class Main {
public static void main(String[] args) {
try {
try {
Desktop.getDesktop().browse(new
URI("file:///home/xavier/Public"));
} catch (IOException ex) {
// ...
}
} catch (URISyntaxException ex) {
// ...
}
}
}
Sous Windows, il faut par exemple : new URI("file:///D:/test")
Bien sur, il est possible d'utiliser un JFileChooser ou la méthode exec de Runtime. Ce n'est pas exactement ce qui me pose problème. Ce qui me chagrine est le fait que
sous windows XP : Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) fonctionne correctement.
sous linux (Fedora 11) Desktop.isSupported () == true Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE) == true Desktop.getDesktop ().browse (new File (pathToSave).toURI ()) Lève une IOException !
L'objectif de la class Desktop est d'interagir avec l'environnement de l'utilisateur indépendamment de la plate-forme. C'est génial dans la mesure ou un utilisateur de Linux, Windows ou Mac Os (non testé) retrouve son environnement de travail inchangé quel que soit la plate-forme. L'usage d'un JFileChooser ne répond pas au cahier des charges de mon application et l'usage de start est clairement une manœuvre de contournement d'un comportement anormal. De plus il existe un risque suivant la distribution de Linux utilisé de ne pas retrouver exactement la même commande.
Pour l'instant, j'indique simplement à l'utilisateur qu'il est impossible de parcourir le répertoire automatiquement et je l'invite à le faire manuellement. C'est dommage et je me demande comment corriger cela sans rentrer dans l'usage de mécanisme qui ne sont pas pérenne.
Bonjour, En lisant ton post original, je me suis dit "Tiens, pourquoi j'ai jamais pensé à ouvrir l'explorer comme çà ?". Alors j'ai essayé et comme toi : Sous Vista : ok Sous Ubuntu : IOException
Puis j'ai joué un peu avec les URI et j'ai trouvé le truc. Ca fonctionne avec Ubuntu, à toi de me dire si c'est pareil avec Fedora :
public class Main { public static void main(String[] args) { try { try { Desktop.getDesktop().browse(new URI("file:///home/xavier/Public")); } catch (IOException ex) { // ... } } catch (URISyntaxException ex) { // ... } } }
Sous Windows, il faut par exemple : new URI("file:///D:/test")
Merci pour l'information. J'avais déjà tenté mais si cela fonctionne chez-vous c'est sans dou te que j'ai loupé quelque chose. Je test ce soir (Station linux hs pour l'instant au travail) et je poste dans la foulée.
Merci.
Francis JUGE-BOIRARD
Merci pour l'information.
J'avais déjà tenté mais si cela fonctionne chez-vous c'est sans dou te
que j'ai loupé quelque chose. Je test ce soir (Station linux hs pour
l'instant au travail) et je poste dans la foulée.
Merci pour l'information. J'avais déjà tenté mais si cela fonctionne chez-vous c'est sans dou te que j'ai loupé quelque chose. Je test ce soir (Station linux hs pour l'instant au travail) et je poste dans la foulée.
Merci.
Francis JUGE-BOIRARD
Francis JUGE-BOIRARD
Bon et bien c'est non !!! Ci-dessous l'incroyable et génialissime bout de code que j'utilise pour simplifier au maximum ce test :
import java.awt.Desktop; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; public class TestDesktop { public static void main(String[] args) throws IOException, URISyntaxException { if (Desktop.isDesktopSupported ()) { if (Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE)) Desktop.getDesktop ().browse (new URI ("file:///root/")); } } }
En désespoir de cause j'ai même exécuter le code en tant que root résultat identique. (L'uri dans le code ci-dessus explique cela) Je soupçonne un problème de configuration des associations de fichier sur mon système.
Encore plus frustrant, j'ai utilisé le même bout de code avec des répertoire n'existant pas ou, à l'inverse, des répertoire possédant les droits drwxrwxrwx résultat strictement identique.
Ultime information : java sun jre 1.6.0_13. Histoire de faire un tour complet de la question, je suis en train d'installer la 1.6.0_14 mais si ça fonctionne, je mange mon chapeau.
Francis JUGE-BOIRARD
Bon et bien c'est non !!!
Ci-dessous l'incroyable et génialissime bout de code que j'utilise pour
simplifier au maximum ce test :
import java.awt.Desktop;
import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
public class TestDesktop
{
public static void main(String[] args)
throws IOException, URISyntaxException
{
if (Desktop.isDesktopSupported ())
{
if (Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE))
Desktop.getDesktop ().browse (new URI ("file:///root/"));
}
}
}
En désespoir de cause j'ai même exécuter le code en tant que root
résultat identique. (L'uri dans le code ci-dessus explique cela)
Je soupçonne un problème de configuration des associations de fichier
sur mon système.
Encore plus frustrant, j'ai utilisé le même bout de code avec des
répertoire n'existant pas ou, à l'inverse, des répertoire possédant les
droits drwxrwxrwx résultat strictement identique.
Ultime information : java sun jre 1.6.0_13. Histoire de faire un tour
complet de la question, je suis en train d'installer la 1.6.0_14 mais si
ça fonctionne, je mange mon chapeau.
Bon et bien c'est non !!! Ci-dessous l'incroyable et génialissime bout de code que j'utilise pour simplifier au maximum ce test :
import java.awt.Desktop; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; public class TestDesktop { public static void main(String[] args) throws IOException, URISyntaxException { if (Desktop.isDesktopSupported ()) { if (Desktop.getDesktop ().isSupported (Desktop.Action.BROWSE)) Desktop.getDesktop ().browse (new URI ("file:///root/")); } } }
En désespoir de cause j'ai même exécuter le code en tant que root résultat identique. (L'uri dans le code ci-dessus explique cela) Je soupçonne un problème de configuration des associations de fichier sur mon système.
Encore plus frustrant, j'ai utilisé le même bout de code avec des répertoire n'existant pas ou, à l'inverse, des répertoire possédant les droits drwxrwxrwx résultat strictement identique.
Ultime information : java sun jre 1.6.0_13. Histoire de faire un tour complet de la question, je suis en train d'installer la 1.6.0_14 mais si ça fonctionne, je mange mon chapeau.
