On Thu, Jan 04, 2007 at 10:23:53AM +1800, Bo Peng wrote:
> >> I think middle-button-paste should keep lyx formating, if this can be
> >> done properly, in terms of inter-application paste. Actually, I do not
> >> mind at all that xterms paste lyx selection with extra stuff like
> >> \begin{table}.
Am Mittwoch, 3. Januar 2007 19:33 schrieb Bo Peng:
> We somehow agreed upon many things. This has been encouraging. You
> know, I was afraid that people just like the current clipboard
> behaviors and would denounce any change. :-)
I forgot to write on thing yesterday: Although you did not convinc
Abdelrazak Younes wrote:
Georg Baum wrote:
As long as these requirements are fulfilled I don't care very much
whether the middle mouse button preserves formatting if it pastes
something from within LyX or not. I do care about the format of the
external selection: That should always be plain te
This is certainly possible. I only do not see the advantage in doing so,
only a problem: This representation would directly reflect the internal
data structure, therefore it could change quite often, even in the stable
series. That means that this internal data structure should not be used by
any
Am Mittwoch, 3. Januar 2007 17:51 schrieb Bo Peng:
> Let us think a bit more about this MIME approach:
> 1. it removes the need for internal clipboards.
At the cost of either performance or another serialization format.
> 2. it stops confusions about pasting under different contexts. I guess
> yo
Am Mittwoch, 3. Januar 2007 16:55 schrieb Bo Peng:
> Yes. Clear separation of copySelection and copyClipboard in function
> name or parameter is needed. However, there is no need for a parameter
> LFUN_COPY since LFUN_COPY is LFUN_COPY, i.e., copy content to system
> clipboard.
Exactly.
> I think
Georg Baum wrote:
As long as these requirements are fulfilled I don't care very much whether
the middle mouse button preserves formatting if it pastes something from
within LyX or not. I do care about the format of the external selection:
That should always be plain text, definitely not LyX syn
Am Mittwoch, 3. Januar 2007 15:56 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Almost all of the remaining stuff looks wrong, too. Can't you simply
fill
> > the selection at the right time without touching LFUN_COPY?
>
> Of course I can. But then it will not be possible to keep the LyX
>
> BTW, http://doc.trolltech.com/4.2/qclipboard.html says that we can put
> Mime data to system clipboard. Can we unify our internal clipboard
> buffers as system clipboard under differnt mime formats?
We could but this would mean that we have to parse the string (which
would be in the LyX format)
Bo Peng wrote:
> I think middle-button-paste should keep lyx formating, if this can be
> done properly, in terms of inter-application paste. Actually, I do not
> mind at all that xterms paste lyx selection with extra stuff like
> \begin{table}.
I would mind personally.
OK, we need internal sel
Georg Baum wrote:
Am Mittwoch, 3. Januar 2007 17:13 schrieb Abdelrazak Younes:
OK, that's just semantics but I got your point. I am going to reorganise
CutAndPaste.C so that we can reuse some of the algorithms for
selection as well as clipboard.
Please wait a bit, I am currently doing some
> I think middle-button-paste should keep lyx formating, if this can be
> done properly, in terms of inter-application paste. Actually, I do not
> mind at all that xterms paste lyx selection with extra stuff like
> \begin{table}.
I would mind personally.
OK, we need internal selection for windo
Am Mittwoch, 3. Januar 2007 17:13 schrieb Abdelrazak Younes:
> OK, that's just semantics but I got your point. I am going to reorganise
> CutAndPaste.C so that we can reuse some of the algorithms for
> selection as well as clipboard.
Please wait a bit, I am currently doing some work on that (
Bo Peng wrote:
> I believe that cutSelection does already what you now added.
Not since I removed the clipboard fill-in from copySelection(). That's
because cutSelection() is calling copySelection() which do the filling
in without my patch.
Yes. Clear separation of copySelection and copyClipbo
> I believe that cutSelection does already what you now added.
Not since I removed the clipboard fill-in from copySelection(). That's
because cutSelection() is calling copySelection() which do the filling
in without my patch.
Yes. Clear separation of copySelection and copyClipboard in function
Georg Baum wrote:
Am Mittwoch, 3. Januar 2007 15:01 schrieb Abdelrazak Younes:
Abdelrazak Younes wrote:
The mixing comes from the fact that cap::copySelection() fills in
theClipboard(), independantly of the caller.
That is alright. Why do you think this should be changed?
See below.
I bel
Am Mittwoch, 3. Januar 2007 15:01 schrieb Abdelrazak Younes:
> Abdelrazak Younes wrote:
> > The mixing comes from the fact that cap::copySelection() fills in
> > theClipboard(), independantly of the caller.
That is alright. Why do you think this should be changed?
> > This patch fixes this by
Abdelrazak Younes wrote:
The mixing comes from the fact that cap::copySelection() fills in
theClipboard(), independantly of the caller. This patch fixes this by
properly filling in theSelection() or theClipboard() depending on the
argument at LFUN_COPY time. It also fills in the X Selection at
The mixing comes from the fact that cap::copySelection() fills in
theClipboard(), independantly of the caller. This patch fixes this by
properly filling in theSelection() or theClipboard() depending on the
argument at LFUN_COPY time. It also fills in the X Selection at mouse
release time instea
19 matches
Mail list logo
