Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use ? #1

Open
dtcg opened this issue Jan 10, 2022 · 10 comments · May be fixed by #2
Open

How to use ? #1

dtcg opened this issue Jan 10, 2022 · 10 comments · May be fixed by #2

Comments

@dtcg
Copy link

dtcg commented Jan 10, 2022

This version feels very sandboxed, hence unusable yet for translation.

Current issues :

  • Upon new project creation, after selecting a path, no folder architecture actually gets created and project isn't actually saved.
  • Plugin folder is nowhere to be found.

OmegaT version: 5.7.0
Operating System: KDE neon 5.23
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.3
Kernel Version: 5.11.0-43-generic (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ m3-6Y30 CPU @ 0.90GHz
Memory: 3,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 515

@dtcg
Copy link
Author

dtcg commented Jan 10, 2022

Okay!
After some testing, I have solved my own issues :)

  • I guess due to the flatpack nature, many folders are access-restricted. On my system, I could only create a project folder architecture under ~/Documents, Not convenient but it works. (@devs : any way to configure folder access?)
  • I have managed to copy a plugin file (Okapi) to the correct directory and everything works as intended. You´ll need to use the following command:
    sudo cp /path_to_your_plugin_file /var/lib/flatpak/app/org.omegat.OmegaT/current/active/files/share/omegat/plugins
    (@devs : probably worth adding to the documentation)

Hope this helps passersby 👍

@andrewshadura
Copy link

@jacobzimmermann, you were the last who updated this package, could you please have a look? I just tried this version and indeed it’s very very limited. I never store my translation projects in ~/Documents, and I wouldn’t like to adapt just to be able to use newer OmegaT (as opposed to 3.x I packaged for Debian).

@vescovaccio
Copy link

vescovaccio commented Feb 1, 2022

Hi Andrew, I'm not Jacob, but I've been looking into the packaging of OmegaT in Flatpak, Snap and .deb. Jacob's done a wonderful job of packaging OmegaT as a Flatpak. The very nature of Flatpak is that it is sandboxed, meaning that it doesn't have free reign over the whole of your system, and is only allowed to access the folders you specify. Keeping translations in the Documents folder seems like a natural place to keep them, and so this is surely by design, not accident. This design prevents potentially malicious code hosing your system by having root access to everything. If you want to specify another folder, why don't you look into the code and find a way of specifying the folder you want? You can then fork it and build it for yourself. Changing the upstream design might not suit everyone else, you see? The Snap has the same feature/problem and is a little behind in its version. I don't know what packaging repos you are using, but the .deb in the Ubuntu repo is certainly way behind. The alternative is to simply download OmegaT from its official website. Build 5.7.0 is incredibly stable. You don't even have to install it. Just launch the .jar inside the folder from the command line, or create a .desktop launcher for yourself or something. By opting for the Flatpak of any software, you are kinda accepting that it's gonna be sandboxed and have limited access. Where is the best place to keep documents if not in the documents folder? If you're looking for a quicker fix, you might just want to give the Flatpak special permission to access another folder. You can do this in the command line with: flatpak override <package_name_here> --filesystem=<path_here>. Or if you want to fork the code, and give it wider access, and then build it for yourself, all you would need to do is change line 10 in the .yml. For example, change "- --filesystem=xdg-documents" to "- --filesystem=home" to give it access to the whole of your Home folder.

@andrewshadura
Copy link

Where is the best place to keep documents if not in the documents folder?

Well, I would expect to be able to use any location in my home directory. I personally use ~/projects for everything and ~/projects/translation-projects for translation stuff.

The very nature of Flatpak is that it is sandboxed, meaning that it doesn't have free reign over the whole of your system, and is only allowed to access the folders you specify.

True, but for that to work correctly the app needs to use portals to allow the user to specify any location they want at runtime. Whereas OmegaT doesn’t do that, so limiting users to ~/Documents is not appropriate.

If you want to specify another folder, why don't you look into the code and find a way of specifying the folder you want? You can then fork it and build it for yourself.

The whole point of using a version from Flathub is to avoid the need to build it myself.

Changing the upstream design might not suit everyone else, you see?

Well, if it doesn’t suit its users, who is it for?

@vescovaccio
Copy link

I'm a user and it suits me fine. No code can ever cover everyone's use case. Look, why don't you do as I suggested in my edited comment above, giving the Flatpak special permission to access another folder with this in the command line: flatpak override <package_name_here> --filesystem=<path_here>. Does that solve your use case?

@andrewshadura
Copy link

If this suits you, why are you commenting on this issue? It clearly doesn’t suit a lot of people, since clearly not everyone keeps everything they work on in ~/Documents. Please stop trying to convince us we’re doing things wrong, thank you very much.

@andrewshadura andrewshadura linked a pull request Feb 1, 2022 that will close this issue
@vescovaccio
Copy link

The whole point of using a version from Flathub is to avoid the need to build it myself.

Well, if it doesn’t suit its users, who is it for?

If you feel so strongly, then submit a pull request.

@dtcg
Copy link
Author

dtcg commented Feb 1, 2022

Hi @andrewshadura ,

if you install Flatseal (also a Flatpak app), you'll be able to easily manage any Flatpak permissions with a nice GUI.

Within Flaseal, what you're looking for is under "OmegaT > Filesystem > All user files (/home)"

Hope this helps

@jweickm
Copy link

jweickm commented Jan 7, 2024

Okay! After some testing, I have solved my own issues :)

* I guess due to the flatpack nature, **many folders are access-restricted**. On my system, I could only create a project folder architecture under ~/Documents, Not convenient but it works. (@devs : any way to configure folder access?)

* I have managed to copy a plugin file (Okapi) to the correct directory and everything works as intended. **You´ll need to use the following command:**
  `sudo cp /path_to_your_plugin_file /var/lib/flatpak/app/org.omegat.OmegaT/current/active/files/share/omegat/plugins`
  (@devs : probably worth adding to the documentation)

Hope this helps passersby 👍

Thank you! This really helped me finally install the plugins. I followed the documentation for the plugin installation and put them into ~/.omegat/plugins but it never worked (even after using Flatseal to allow OmegaT to access the home directory). So thank you for that!

@K0-RR
Copy link

K0-RR commented Sep 26, 2024

Yeah, having to use another application (flatseal) or worse, command line, to get access to the files stored in the Downloads folder is not a great UX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants