preserve history order, automatic pasting, &c.
Brought to you by:
rickyrockrat
Menu
▾
▴
#37 preserve history order, automatic pasting, &c.
Most X clipboard managers appear to follow a common model and they move the selected entry to the top of the stack (instead of preserving the history).
It's essential to my purposes that the order is preserved, and also that the system paste commands return the last copied item.
Please implement history preservation and pasting directly from a given register.
It's not clear what you are talking about. Parcellite *does* put the selected entry at the top of the stack and drops the oldest entry off the history. Double-check your settings and figure out which clip it's getting. It may be useful to check all three boxes under 'Clipboards' under preferences->Behavior.
I think he means that when he clicks on an item in the history list it moves to the top of the list, and he doesn't want this to happen.
I suppose it was more difficult to make automatic pasting work with X
and that's why these programs clobber the system clipboard instead
in any case, here is an outline of the behaviour which makes most sense to me
(and matches the behaviour on other systems)
- the history order is preserved (unless one deliberately modifies it)
- selecting an item from the history causes it to be pasted immediately
- the system clipboards remain unchanged by selecting an item form the history
this means that the system clipboards behave as they normally would
and the clipboard manager essentially watches them
recording history without interference
Interesting. I can see the use case for this. It should only be an option though.
> matches the behaviour on other systems
What systems? I've never seen a system like that. Unless it was an option that I chose not to enable, and have forgotten about it.
With this proposed behaviour, presumably if tracking of the primary selection and the clipboard are both enabled, you want it to be possible for the current clipboard to drop off the bottom of the list, so it is no longer possible to see what it is (or even know that there is something in the clipboard). Is that right?
> this means that the system clipboards behave as they normally would and the clipboard manager essentially watches them
FWIW I think that the main reason a lot of people use a clipboard manager in Linux is because they don't like the way the X clipboard works. In particular they want the clipboard or primary selection contents to stay in the clipboard if the program that put them in the clipboard is closed.
> What systems?
several clipboard extensions (PTH Clipboard, Butler, &c.)
work like this under OS X (and older versions of Mac OS)
and it appears that Ditto (Windows) does too
> With this proposed behaviour, presumably if tracking of the primary
> selection and the clipboard are both enabled, you want it to be possible
> for the current clipboard to drop off the bottom of the list, so it is no
> longer possible to see what it is (or even know that there is something in
> the clipboard). Is that right?
no, I think CLIPBOARD should correspond to the top of the stack
if PRIMARY is integrated, then I guess it clobbers CLIPBOARD
but I prefer to keep them separate, running one buffer for each
> they want the clipboard or primary selection contents to stay in
> the clipboard if the program that put them in the clipboard is closed
yes, thanks for reminding me
I also want that and I should have been more clear
I'm just used to a different context of expected behaviour
indeed, it seems fundamental
to use the clipboard to share data
between different programs
I'll try again
1 - system clipboards should be preserved
(existing past parent program termination)
2 - a running buffer should be maintained
(for each: PRIMARY and CLIPBOARD)
3 - choosing a register from the buffer/stack = paste register contents
(without modifying the stack order, or CLIPBOARD/PRIMARY)
I use a key binding to
display the stack as menu (for interactive selection)
and also separate bindings (one for each)
to paste directly from the first few registers
(I frequently use the first 3-6)
I hope that's more comprehensible
for the record
I just tried Ditto (and some others under Windows)
but they they all rearrange the stack
replacing the system clipboard
when an item is selected from the history
I'm all for options
but the way it works on the Mac
is much more useful to me:
- read (don't write) system clipboard
- preserve history order
- paste directly from history
- key bindings for first several registers
This is not a trivial matter to accomplish, since by definition, X uses one of the clipboards to paste from, and more importantly, all applications on X EXPECT this behavior. Changing it would require re-writing all X applications, which is not going to happen.
The matter of history sorting is addressed with the option 'Current Entry on Top', so that feature is available in 1.1.4.
I wonder if Mac uses a Write to clip/wait on clip paste/restore clip, but to the user is appears to not 'write', and paste directly from history.
I'm not sure you mean by 'registers'. I know what that means in Assembly :). Do you mean history entries?
then use SECONDARY
and in any case
if the system clipboard must be written to
then restore it afterwards
yes
I like to have key bindings for the first several entries/registers
because I can remember what's in them
and it's faster than using the menu
It doesn't matter which clipboard. In X, Ctrl-C goes to the CLIPBOARD, and the mouse copy goes to the PRIMARY (those are defs). So if you Ctrl-V paste, it comes from CLIPBOARD, and a mouse middle button comes from PRIMARY.
Here is a nice article on X and it's clipboards. According to them, I could use SECONDARY, but it's doubtful if your application would use it.
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt
If you want a preference for using SECONDARY instead of the others, that is possible, but I'm thinking useless unless you have a specific application written to take advantage of it.
The other idea, that of leaving the clipboard(s) untouched is still not a trivial matter, since parcellite is not in control of the clipboards.
Unfortunately, it means digging into the internals of X and Xlib, and deciphering the Xevents, which takes time, but I would rather stay with GTK. There may be a way to do this with signals on owner changes, but the difficulty is discovering who the owner really is.
there's obviously some miscommunication here
that kills Parecelite for me
as I would rather avoid Gnome
(and the tool kit they hijacked)
http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/
GTK is used for quite a few applications - without GNOME.
I don't like Gnome either, and prefer XFCE4. GTK is just a toolkit, like QT, and I particularly dislike the Unity interface. I also do not plan on using GTK+3, but so far, the 2.14 and above works with a wide variety of platforms. I've been very careful to not depend on Unity - and I will continue to release code without libappindicator dependencies. My code detects Unity, and if it's not running there goes back to the old behavior that I use all the time.
I can build applications in GTK and they will even run on Windows, so clearly GNOME is not needed - while GNOME needs GTK, the inverse in not true. I shudder to think of the day that GTK2 is no longer in the repositories.
If you are saying you no longer want to use GTK2.0, have a look at
apt-cache rdepends libgtk2.0-0
You will find a long list of applications (and libraries) that you will need to do without until all of us re-write our software to use something besides GTK :). I think before that happens, there will be a maintenance fork of GTK2.x - there may already be.
But that's the beauty of Open Source. You are free to use whatever program you want.
Last edit: rickyrockrat 2013-03-11
This feature is addressed by the option 'current entry on top' in Preferences->Display. Closing this feature, since the creator is not interested in Parcellite anyway.