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

Add Xsel local support #436

Open
ALiwoto opened this issue Jul 2, 2021 · 6 comments
Open

Add Xsel local support #436

ALiwoto opened this issue Jul 2, 2021 · 6 comments

Comments

@ALiwoto
Copy link

ALiwoto commented Jul 2, 2021

I'm currently writing a package and a game in C#, and I'm using TextCopy package for copying and pasting texts from InputElement.
I don't want my users on linux install xsel with command apt install, instead I will provide the binary file in my game directory, so I need to run the xsel directly.
Is it possible to add support for using xsel locally?
I think the only thing you have to change is in BashRunner class, so it runs ./xsel or something like this.
Also a bool variable that users can set if they want to use it locally.
Also I can create a PR for it if this idea is acceptable.

@SimonCropp
Copy link
Collaborator

wouldn’t this be possible without any changes by, at app startup, adding your xsel to the path if u dont find it there?

@ALiwoto
Copy link
Author

ALiwoto commented Jul 3, 2021

wouldn’t this be possible without any changes by, at app startup, adding your xsel to the path if u dont find it there?

Yes, that's a good idea as well,
But I can see some problems here:

  1. Doesn't it mean changing "User's configurations" by adding a new address to PATH? (Even if it's only temporary and it only effects current session). I really prefer not to do this.
  2. Won't it increase time order of application? I mean we have to do two things here: setting path and then using xsel.

Hasn't this idea worth to be added to the library as a new feature? (of course only in linux)

@SimonCropp
Copy link
Collaborator

ok i will accept a pr for this

@ALiwoto
Copy link
Author

ALiwoto commented Jul 4, 2021

@SimonCropp , I think I'm almost done, will send the pr
but before that, I'm getting this compiler warning:

The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. [TextCopy]

Can you explain me a little bit why did you use string? (which is equal to Nullable)?
I know it doesn't have any connection to me, and I don't want to bother you, but is there any reason for it?

Like you used it here:

    public static string? GetText()
    {
        var tempFileName = Path.GetTempFileName();
        try
        {
            InnerGetText(tempFileName);
            return File.ReadAllText(tempFileName);
        }
        finally
        {
            File.Delete(tempFileName);
        }
    }

Just want to increase my knowledge and experience a little bit*

I mean a string is already nullable, right? It's not a value, it's reference so it can be passed as null, then why we use more classes for it?
Nullable<T> is a generic class, right?
By doing so we are just wasting our memory, right?
Also I know this is somehow off-topic in this issue, but I couldn't ask you this in any other place

@ALiwoto
Copy link
Author

ALiwoto commented Jul 4, 2021

You can see my pull request here: #437

@principis
Copy link

1 Doesn't it mean changing "User's configurations" by adding a new address to PATH? (Even if it's only temporary and it only effects current session). I really prefer not to do this.

The PATH is just an environment variable as any other. So if you change it in a process, it only counts for the current environment (thus process). If you export the variable it will be used in the environment of child processes.

Here is an example:

#!/bin/bash
echo "configured path: $PATH"
echo "default xsel: $(which xsel)"
echo "Changing path in subshell..."
bash -c 'PATH="/home/arthur:$PATH" && echo "sub path: $PATH" && echo "sub xsel: $(which xsel)"'
echo "xsel after changing path in subshell: $(which xsel)"
echo "path after change in subshell: $PATH"

This outputs:

configured path: /usr/local/bin:/usr/bin
default xsel: /usr/bin/xsel
Changing path in subshell
sub path: /home/arthur:/usr/local/bin:/usr/bin
sub xsel: /home/arthur/xsel
xsel after changing path in subshell: /usr/bin/xsel
path after change in subshell: /usr/local/bin:/usr/bin

This means your could just change the path when starting the game (or even just before executing TextCopy) and it would work fine without any side-effects.

2 Won't it increase time order of application? I mean we have to do two things here: setting path and then using xsel.

Manipulating the path shouldn't be slow and you could do it at startup

Changing the code for this exact purpose is complicating things. Using environment variables is much easier.
Hopefully this solves your problem!

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

No branches or pull requests

3 participants