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
so ok, i'm not going to commit this. if you want me i can produce the
patch,
which will remove the caching,
>>>
>>> Yes. Please do that.
>> No please, I think I have the solution.
>
> Please svn update and try again.
yesss! good work Abdel :)
pavel
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Pavel Sanda wrote:
Thinks tend to change, and I am pretty sure this was once called
once per keystroke.
If the 'paste' button is visible, it is called 'once' per keystroke!
Do you have the main toolbars switched off Pavel?
yes i have all stan
Abdelrazak Younes wrote:
Pavel Sanda wrote:
Thinks tend to change, and I am pretty sure this was once called
once per keystroke.
If the 'paste' button is visible, it is called 'once' per keystroke!
Do you have the main toolbars switched off Pavel?
yes i have all standard buttons on.
In any c
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
Pavel Sanda wrote:
Thinks tend to change, and I am pretty sure this was once called
once per keystroke.
If the 'paste' button is visible, it is called 'once' per keystroke! Do you
have the main toolbars switched off Pavel?
yes i have all standard buttons on.
In any case this patch is wrong be
> 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
>> Thinks tend to change, and I am pretty sure this was once called
>> once per keystroke.
>
> If the 'paste' button is visible, it is called 'once' per keystroke! Do you
> have the main toolbars switched off Pavel?
yes i have all standard buttons on.
> In any case this patch is wrong because it
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
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
If the 'paste' button is visible, it is called 'once' per keystroke!
Do you have the main toolbars switched off Pavel?
It is 'paste selection', I think. Is it in the toolbar?
Ah... right! The original problem was with
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> If the 'paste' button is visible, it is called 'once' per keystroke!
> Do you have the main toolbars switched off Pavel?
It is 'paste selection', I think. Is it in the toolbar?
> In any case this patch is wrong because it is turning around the real
Andre Poenitz wrote:
On Wed, Dec 12, 2007 at 12:04:14AM +0100, Pavel Sanda wrote:
reasons why
we dont ask directly
qApp->clipboard()->text(QClipboard::Selection).isEmpty() ?
The only reason was speed issue.
what about to call this whenever middle button is clicked ?
Might work. Otoh we get t
On Wed, Dec 12, 2007 at 12:04:14AM +0100, Pavel Sanda wrote:
> > > >> reasons why
> > > >> we dont ask directly
> > > >> qApp->clipboard()->text(QClipboard::Selection).isEmpty() ?
> > > >
> > > > The only reason was speed issue.
> > >
> > > what about to call this whenever middle button is clicke
> > >> reasons why
> > >> we dont ask directly
> > >> qApp->clipboard()->text(QClipboard::Selection).isEmpty() ?
> > >
> > > The only reason was speed issue.
> >
> > what about to call this whenever middle button is clicked ?
>
> Might work. Otoh we get the signal delivered anyway...
i really d
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
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+paste it with ctrl+c and ctrl+v
4. Mark something outsi
40 matches
Mail list logo
