FS#23747 - [autocutsel] add it to xinitrc.d

Attached to Project: Community Packages
Opened by Chris Redden (redden0t8) - Wednesday, 13 April 2011, 12:58 GMT
Last edited by Stefan Husmann (stefanhusmann) - Thursday, 14 April 2011, 21:00 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Stefan Husmann (stefanhusmann)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

autocutsel is very poorly documented, and it's functionality is pretty standard. It seems like a good candidate for inclusion in /etc/X11/xinit/xinitrc.d/

Case of the confusion it can cause:
https://bbs.archlinux.org/viewtopic.php?id=116639
This task depends upon

Closed by  Stefan Husmann (stefanhusmann)
Thursday, 14 April 2011, 21:00 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Added install file as workaround.
Comment by Stefan Husmann (stefanhusmann) - Wednesday, 13 April 2011, 15:52 GMT
done in -5.
Comment by Greg (dolby) - Wednesday, 13 April 2011, 18:07 GMT
What if the user wants different settings?
Comment by Chris Redden (redden0t8) - Wednesday, 13 April 2011, 18:34 GMT
You can use XResources, can you not?

Besides, aren't you allowed to edit files in /etc? Just replace them with the values you want and on upgrade pacman will do its .pacnew thing.
Comment by Greg (dolby) - Wednesday, 13 April 2011, 20:14 GMT
A user isnt allowed to edit files in /etc no. If one user in the system wants to use autocutsel this way you're forcing everyone to use it.
And this is changing the default way of dealing with the X clipboard, so its rather important IMO.
Comment by Stefan Husmann (stefanhusmann) - Wednesday, 13 April 2011, 23:38 GMT
A user may not do so. But an admin may install autocutsel. With doing so, he wants to archive something for his users. And as far as I understood, it is most likely that the entries made in the file in .xinitrc.d are the sanest defaults. If he does not like these defaults, it is better not to install autocutsel at all.

BTW, the user can have his own .xinitrc and redefine things there.
Comment by Greg (dolby) - Thursday, 14 April 2011, 00:04 GMT
You are overcomplicating things for absolutely no reason and implementing this is plain wrong, VERY wrong.
The default should be X's default, not the autocutsel's custom configuration. & yes it should be the default even if autocutsel is installed.
It would be better to add documentation to the package if you think its lacking it, maybe a custom README file for users too lazy to consult the wiki.
This is overkill.
Comment by Stefan Husmann (stefanhusmann) - Thursday, 14 April 2011, 01:16 GMT
I do not get your point, if there is any.
Comment by Loui Chang (louipc) - Thursday, 14 April 2011, 03:15 GMT
I am not sure which would be right either way.

Greg's point is that you should not enable autocutsel in the X config just by
installing it. Some might call this 'The Arch Way', which I generally agree
with. Since I don't plan on installing autocutsel it would not bother me though.

If I was a user that wanted autocutsel I might be annoyed at having to perform
an extra step of enabling it in the config. There are some packages that irritate
me though because they do have things enabled by default which I don't think they
should, and it causes me extra work to remove that.
Comment by Greg (dolby) - Thursday, 14 April 2011, 04:20 GMT
Its not about the Arch Way and philosophies. Its entirely practical. I've come up with an example where doing such a thing actually is useful, hoping you'll be able to understand why this is a bad idea. See the application lesspipe: http://www.archlinux.org/packages/community/i686/lesspipe
Instead of the user defining in his environment the LESSOPEN variable (breaking the Arch Way blah blah blah useless useless useless) ,
it does so globally by a script in etc/profile.d/ which reads:
"export LESSOPEN='|/usr/bin/lesspipe.sh %s'" thus forcing the use of lesspipe on all users on the system same as your autocutsel.sh.
There are two major differences between the two:
a) Unlike autocutsel, lesspipe doesnt take arguments. You either use it or you don't.
b) More importantly, it doesnt change the way less works. it just extends it. Autocutsel on the other hand changes the way a used by everyone feature works. It should be left up to the user to enable it should he wishes to. Not the other way around.
Comment by Loui Chang (louipc) - Thursday, 14 April 2011, 04:38 GMT
But, you are completely disregarding those people who find that 'extension'
of less annoying. This is really the same thing.

http://gicl.cs.drexel.edu/people/tjkopena/wiki/pmwiki.php?n=SWAT.LESSOPEN
Comment by Greg (dolby) - Thursday, 14 April 2011, 05:14 GMT
OK,what about a) though?
In the lesspipe example LESSOPEN is an environment variable i can just unset and set as i please on my own user environment.
What happens if the user wants to change the autocutsel behaviour but has no rights to edit in /etc? And how do two running instances of autocutsel behave invoked with different arguments?
Comment by Ray Rashif (schivmeister) - Thursday, 14 April 2011, 06:24 GMT
Could someone please provide an example where this being implemented would cause (a) headache(s)?
Comment by Heiko Baums (cyberpatrol) - Thursday, 14 April 2011, 06:45 GMT
I don't know autocutsel but from what I read about this now, autocutsel should definitely not become a default or get a system wide config which can't be changed by the users.

I regularly use both standard X buffers and I need both. I need the Ctrl+C/Ctrl+V method as well as just pasting the selection with the middle mouse click. Btw., usually the clipboards of most DEs - at least the ones of KDE and Xfce - already let the user decide and configure how both buffers are handled, if they are synchronized or if they are separated.

So I don't think there's a need for such a tool like autocutsel and it definitely doesn't have to become a default, means a dependency. Users who want autocutsel can, of course, install it. But there shouldn't be any system wide config which forces the users to use it the way the admin wants them to use it.

And if this tool is poorly documented it should first be documented. What shall users do with a tool about which they don't know anything?
Comment by Stefan Husmann (stefanhusmann) - Thursday, 14 April 2011, 10:48 GMT
Okay, maybe the best compromise is to take the change back and write a short message in an install file. Done in -6.

Loading...