Working directory issue on Linux

[Kimmo Elo]

Hi,

I have been using visone for years and am very satisfied with it. Good
and robust network analysis tool.

There is one thing I find a bit disturbing and my question is, could
there be a solution for it. I run visone on a Linux system (Linux Mint),
so this might be Linux-related only.

The problem: visone does not use the path of the active network as its
present working directory. Instead, when I e.g. export a graph or want
to use the "Save as..." option, visone always opens the file dialog at
my home directory. Could it be possible to use the path of the active
graph as the default directory when doing file operations? I am quite
convinced, that this information could be passed to the file dialog as a
parameter.

Being totally aware that this is a minor issue, I still find it a bit
stressing to browse through my directory structure to find the correct
location :-)

Best,

Kimmo

[Müller Julian]

Hi Kimmo,

Let me briefly explain how visone currently handles the initial directory in the file dialog for opening, saving and exporting:

visone remembers the directory of the last file it successfully opened and uses this as the initial directory of the file dialog when you try to open a file. Similarly, it remembers the directory you last saved or exported to and uses this as the initial directory when you open the file dialog for saving or exporting.

If this initial directory no longer exists, then it depends on Java and the operating system what happens, but I think the file dialog usually defaults to the home or personal documents directory.

So in general, visone doesn't use the directory of the currently selected network, it uses the directory of the most recently loaded (when opening) or saved/exported file (when saving or exporting). And visone 2 has behaved that way since before I took over as maintainer, perhaps even since the first public release.

If the behavior you observe is different from what I explained here, then this is a bug that would have to be investigated.

I'm not sure what is the most natural behavior here. There are situations where either can be better.
For example, I have taken advantage of this behavior that the initial export directory does not have to agree with the currently selected network's directory by using it to export several images quickly into a directory different from the one where the networks are stored. If the networks' directory was used as the default, I would have had to navigate to the image directory for each exported image or use the the file manager of the operating system to move the images afterwards.

I'm open to changing the initial directory of the file dialog, but only if there is sufficient consensus what the behavior should be. So I would like to hear from others: What behavior would you prefer in practice?

Best,
Julian

[Kimmo Elo]

Hi Julian,

thanks for your informative explanation. However, my visone 2.27.1 does
not behave as you explained :-)

Here a short description of what happens here:

1) I select file -> open: a file dialog appears and I browse to my
network, say, in /home/myhome/networks/sample/ and open a network file
called test.graphmlz. The network appears so the opening was successful.

2) Now I want to open a second network and hit ctrl+o (or use file ->
open). According to you explanation, the file dialog should show me the
directory used in (1). But no, I see my home directory and must start
from there again.

Can someone reproduce this? The same happens with export or save, I must
always start from my home root directory, what is a bit annoying.

Could it be that visone (or Java) has problems with directory names
containing e.g spaces? I have a lot of such directory names and weakly
recall some other programs having had problems with such path names.

For Java Linux Mint uses:
openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment (build 19.0.2+7-Ubuntu-0ubuntu322.04)
OpenJDK 64-Bit Server VM (build 19.0.2+7-Ubuntu-0ubuntu322.04, mixed
mode, sharing)

Best,

Kimmo

--
Kimmo Elo
Bergeninkatu 2 F 59
20320 Turku
GSM: +358 44 342 2122
Sposti: kimmo...@gmail.com
===============================

[Müller Julian]

Hi Kimmo,

I tried to reproduce your problem on a recent Linux Mint (running in the Windows Subsystem for Linux) with OpenJDK 21, but when opening a second network file in both visone 2.27.1 or 2.28, the file dialog was correctly set to the directory the first opened file was in.

> Could it be that visone (or Java) has problems with directory names containing e.g spaces? I have a lot of such directory names and weakly recall some other programs having had problems with such path names.

I made sure to include a space in the directory name, but that didn't break anything as well.

visone itself doesn't perform any manual string manipulation on these file paths. It just uses the appropriate functions of the JFileChooser and File classes in the JDK and only converts between paths and strings to store them using Apache Configuration2.

The behavior you observe suggests a bit that the path visone passes to the file dialog is recognized as invalid for some reason and so the dialog is opened at the default location, the home directory. But I don't know how this can always happen when the directory is actually still there. (If you have some Unicode characters on your paths, you could try if this issue disappears on ASCII-only paths.)

> openjdk version "19.0.2" 2023-01-17

OpenJDK 19 is end of life since early 2023 and doesn't receive any (security) updates anymore. I suggest you upgrade to the most recent OpenJDK or switch to one of the long-term support releases (OpenJDK 8, 17 or 21). visone 2.28 should run on all of these, visone 2.27(.1) unfortunately crashes on JDK 21 or newer when applying the quick layout.

Best,
Julian

[Kimmo Elo]

Hi Julian,

thanks again for your reply. I have now updated openJDK to 21 and visone
to 2.28 and done some more debugging.

I seems, indeed, that umlauts in a path name cause this behaviour. I
opened networks from several locations, all umlaut-less but containing
e.g. spaces or commas - every time the next open dialog showed the
expected directory (i.e. the last used).

But as soon as the path contained an umlaut, the next file open dialog
returned me to my home root directory. And this, although the network
was succesfully loaded in the workspace.

This is not a big problem, but is this something that could be fixed?

Regards,

Kimmo

[Kimmo Elo]

Hi Julian,

thanks again for your reply. I have now updated openJDK to 21 and visone
to 2.28 and done some more debugging.

I seems, indeed, that umlauts in a path name cause this behaviour. I
opened networks from several locations, all umlaut-less but containing
e.g. spaces or commas - every time the next open dialog showed the
expected directory (i.e. the last used).

But as soon as the path contained an umlaut, the next file open dialog
returned me to my home root directory. And this, although the network
was succesfully loaded in the workspace.

This is not a big problem, but is this something that could be fixed?

Regards,

Kimmo

Müller Julian kirjoitti 25.10.2024 klo 14.31:

[Müller Julian]

Hi Kimmo,

> This is not a big problem, but is this something that could be fixed?

Frankly, I don't know if I can fix it at all or how long it will take to find the cause. I tried umlauts in Linux Mint now as well and visone behaved as it should, so I don't have an immediate failing test case.

visone itself doesn't do any kind of manual path or string manipulation, but defers all these manipulation operations to Apache Commons Configuration2 and Java (which internally might defer to the operating system). So the cause is likely hidden somewhere in the JDK or the Commons package, and even if I find it, I might not really be able to do anything about it.

I have one possible guess what's going on. More complex characters like umlauts often don't have a unique representation in Unicode, but several. For example, the umlaut ü can be represented as ü or u+◌̈. Even if you use the same unicode encoding like UTF-8, these two representations result in two different byte sequences. Because of this, there are a number of Unicode normalization algorithms that translate different representations of the same character into the one of them.

Likely, the file paths in on your system use one possible way to represent umlauts. Then visone extracts the directory, stores it as a string in the configuration, extracts it again and then passes it tot he file dialog, which tries to look up the directory. Maybe this sequence of operations triggers some kind of Unicode normalization at some point, replacing one representation of umlauts by another. So the paths in the file system uses one representation of umlauts, but visone/Java ends up looking for a directory using the other representation of umlauts.

Unicode support on Linux often just boils down to "we can just use UTF-8 everywhere and then compare strings byte by byte". That's also the case for file names, which are basically just treated as byte sequences. But that means that file search doesn't handle these different ways to encode the same character in Unicode. Rather, when the byte sequences for the directory names does not match because the representation of an umlaut differs, the directory won't be found anymore.

So my guess is: Somewhere between extraction of the directory path, storage in and extraction from the configuration, conversion into a File object and lookup of the directory, some kind of Unicode normalization is performed. This exchanges the representation of the umlaut character. Because Linux effectively compares file paths byte by byte, lookup of the directory fails, and so the file dialog defaults to the home directory.

Best,
Julian

[Kimmo Elo]

Hi,

sorry for one more post, but I think I figured out the problem - at
least on my Linux Mint: this happens only if there is one or more commas
(",") in the path. Neither umlauts, nor some other punctuation
characters (tested e.g. with ".", ";", ":") cause this.

I still find this a bit annoying, but since this is really marginal and
not directly related to visone, we can close the case :-)

Best,

Kimmo

[Müller Julian]

Hi Kimmo,

I was able to reproduce this.
The problematic character being the comma also sounds like some kind of unintentional string processing when storing the path in the configuration, maybe because the configuration is misinterpreting the path as some kind of property list. I think this is probably easy to fix (in contrast to some umlaut problem).

Best,
Julian

--
You received this message because you are subscribed to the Google Groups "visone-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to visone-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/visone-users/2481bb48-fc82-4543-8950-547787b60879%40gmail.com.