Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The moc file should be enough. I am lost and I suspect a Qt bug here.
Or an incompatibility with some X11 server. Could you, Juegen and
Pavel please list your Qt, OS and X11 version. Maybe we'll f
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The moc file should be enough. I am lost and I suspect a Qt bug here.
Or an incompatibility with some X11 server. Could you, Juegen and
Pavel please list your Qt, OS and X11 version. Maybe we'll find a
comon denominator. A
Juergen Spitzmueller wrote:
Pavel Sanda wrote:
linux, qt 4.3.2, xorg-server 1.1.1, e16 win manager, no desktop manager.
I think the main difference on my side is the Desktop Environment (KDE).
Probably Klipper does the job.
IIRC Klipper mixes X11 selection and clipboard so I understand the
> I think the main difference on my side is the Desktop Environment (KDE).
> Probably Klipper does the job.
is it possible to kill the klipper to see the difference ?
pavel
Pavel Sanda wrote:
> linux, qt 4.3.2, xorg-server 1.1.1, e16 win manager, no desktop manager.
I think the main difference on my side is the Desktop Environment (KDE).
Probably Klipper does the job.
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> The moc file should be enough. I am lost and I suspect a Qt bug here.
> Or an incompatibility with some X11 server. Could you, Juegen and
> Pavel please list your Qt, OS and X11 version. Maybe we'll find a
> comon denominator. At last resort we should
> Could you, Juegen and Pavel please
+JMarc
> list your Qt, OS and X11 version.
linux, qt 4.3.2, xorg-server 1.1.1, e16 win manager, no desktop manager.
> At last resort we should just remove the text_selection_empty_ as it appears
> that it is not critical (because we don't have a paste-sel
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Coming back to this... Aren't you the one using some funky autotools
feature? Could you try with a 'normal' build to see if it solves the
problem? I really can't understand why the signal works for Jurgen and
not for you.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Coming back to this... Aren't you the one using some funky autotools
> feature? Could you try with a 'normal' build to see if it solves the
> problem? I really can't understand why the signal works for Jurgen and
> not for you.
I am using a normal a
Abdelrazak Younes wrote:
Pavel Sanda wrote:
backtracking here: bool GuiSelection::empty, the
text_selection_empty_ is true.
so it seems text_selection_empty_ is not up to date
(GuiSelection::on_dataChanged is not enough to keep it ?).
Seems to be the problem indeed. Might be a bug of
On Tue, Dec 11, 2007 at 03:23:19PM +0100, Pavel Sanda wrote:
> > >> so we have to remember text_selection_empty_ variable? or are there
> > >> other
> > >> reasons why we dont ask directly
> > >> qApp->clipboard()->text(QClipboard::Selection).isEmpty() ?
> > >
> > > The only reason was speed iss
On Tue, Dec 11, 2007 at 12:21:08PM +0100, Pavel Sanda wrote:
> > Seems to be the problem indeed. Might be a bug of Qt or on_dataChanged() is
> > not correctly connected.
>
> do you have an idea which signal i could try?
>
> >Which build system are you using?
>
> make (+qt 4.3.2)
>
> >Maybe G
> >> so we have to remember text_selection_empty_ variable? or are there other
> >> reasons why we dont ask directly
> >> qApp->clipboard()->text(QClipboard::Selection).isEmpty() ?
> >
> > The only reason was speed issue.
>
> "only". Retrieving the selection is _very_ expensive. It's something w
Abdelrazak Younes wrote:
> Juergen, what version do you have?
4.3.1.
Jürgen
Pavel Sanda wrote:
Seems to be the problem indeed. Might be a bug of Qt or on_dataChanged() is
not correctly connected.
do you have an idea which signal i could try?
No, the one chosen should work as indicated by Juergen at least.
Which build system are you using?
make (+qt 4.3.2)
Ju
> Seems to be the problem indeed. Might be a bug of Qt or on_dataChanged() is
> not correctly connected.
do you have an idea which signal i could try?
>Which build system are you using?
make (+qt 4.3.2)
>Maybe GuiSelection.h is not moc'ed?
can you be more verbose? i know that moc files are
Andre Poenitz wrote:
On Tue, Dec 11, 2007 at 08:26:41AM +0100, Abdelrazak Younes wrote:
Pavel Sanda wrote:
i remember many problems with selection wrt speed issues etc - is empty()
used often
so we have to remember text_selection_empty_ variable? or are there other
reasons why we dont ask di
On Tue, Dec 11, 2007 at 08:26:41AM +0100, Abdelrazak Younes wrote:
> Pavel Sanda wrote:
>>> i have recently filled the bug 4394 (1.5 target).
>>> is that recipe reproducible for you ?
>> No. Middle-mouse-button-pasting keeps working.
> It works for 1.5.x
>>> for me debug of actions
Pavel Sanda wrote:
i have recently filled the bug 4394 (1.5 target).
is that recipe reproducible for you ?
No. Middle-mouse-button-pasting keeps working.
It works for 1.5.x
for me debug of actions looks like:
point 3. (in bug 4394 recipe)
LyXFunc::dispatch: cmd: action: 14 arg: 'paragraph' x
> > > > > i have recently filled the bug 4394 (1.5 target).
> > > > > is that recipe reproducible for you ?
> > > >
> > > > No. Middle-mouse-button-pasting keeps working.
> > >
> > > It works for 1.5.x
>
> for me debug of actions looks like:
> point 3. (in bug 4394 recipe)
>
> LyXFunc::dispatch:
> > > > i have recently filled the bug 4394 (1.5 target).
> > > > is that recipe reproducible for you ?
> > >
> > > No. Middle-mouse-button-pasting keeps working.
> >
> > It works for 1.5.x
for me debug of actions looks like:
point 3. (in bug 4394 recipe)
LyXFunc::dispatch: cmd: action: 14 arg:
> > Pavel Sanda wrote:
> > > i have recently filled the bug 4394 (1.5 target).
> > > is that recipe reproducible for you ?
> >
> > No. Middle-mouse-button-pasting keeps working.
>
> It works for 1.5.x but not for 1.6.x. I asked around immediately after
> I noticed this but nobody claimed responsib
On Dec 10, 2007 12:08 PM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> Pavel Sanda wrote:
> > i have recently filled the bug 4394 (1.5 target).
> > is that recipe reproducible for you ?
>
> No. Middle-mouse-button-pasting keeps working.
It works for 1.5.x but not for 1.6.x. I asked around immed
> Pavel Sanda wrote:
> > i have recently filled the bug 4394 (1.5 target).
> > is that recipe reproducible for you ?
>
> No. Middle-mouse-button-pasting keeps working.
what a pity ! :))
p
Pavel Sanda wrote:
> i have recently filled the bug 4394 (1.5 target).
> is that recipe reproducible for you ?
No. Middle-mouse-button-pasting keeps working.
Jürgen
> > The external pasting itself works fine, but it is "disallowed".
>
> This is also what I see with lyx 1.5.3svn. I have to say that it is a
> real pain!
>
> JMarc
> Jean-Marc Lasgouttes wrote:
> > This is also what I see with lyx 1.5.3svn.
>
> I don't.
>
> Jürgen
i have recently filled the
Jean-Marc Lasgouttes wrote:
> This is also what I see with lyx 1.5.3svn.
I don't.
Jürgen
Helge Hafting <[EMAIL PROTECTED]> writes:
> Recipe for reproducing the problem that makes 1.6svn hard to use:
>
> 1. Start lyx under linux, open a document.
>
> 2. Note that stuff marked in other apps can be
> pasted into lyx with a middle-click, as it should.
>
> 3. Mark something in lyx. copy+p
Am Mittwoch, 14. November 2007 13:59:37 schrieb Helge Hafting:
> My guess: LyX has to keep track of whether a middle-click
> paste should come from Lyx itself (formatted) or from the outside. (text)
Actually, it is possible to support formatted and plaintext copy buffers with
X11 (i.e. arbitrary
29 matches
Mail list logo
