Juergen Spitzmueller wrote:
> OK. Then I'll disable the setting of the spaces initially. BTW I'd like to
> adapt the spaces UI more to the other spaces UI in LyX, that is instead of
> the check boxes: a combo "none", "default", "custom". Agreed?
Yes.
> You have used the wrong signal. The attache
Georg Baum wrote:
> Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
> > Very good, thanks. However, I think the "default" switches should be
>
> disabled
>
> > initially at least for non-booktabs tables. It looks rather odd for
>
> those (on
>
> > screen and output).
>
> Only bottom_s
Shouldn't this be "#!/usr/bin/env python\n" ?
I agree that it dosn't matter as the shebang mechanism is never
actually used, but...
Big blush here. Thanks.
Bo
Did you use the rename functionality of svn?
Yes. How to handle the patch under this situation is a mystery to me.
Bo
Edwin Leuven <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > You see... there is the difference, I don't plan on breaking the
| > other frontends just because I am introducing a feature only for one
| > of the frontends.
|
| this is why we should have 1 (and only 1) official frontend
On Sun, Jun 25, 2006 at 03:42:54PM -0500, Bo Peng wrote:
> Index: src/graphics/GraphicsConverter.C
> ===
> --- src/graphics/GraphicsConverter.C (revision 14212)
> +++ src/graphics/GraphicsConverter.C (working copy)
> @@ -161,14 +161
Lars Gullik Bjønnes wrote:
You see... there is the difference, I don't plan on breaking the
other frontends just because I am introducing a feature only for one
of the frontends.
this is why we should have 1 (and only 1) official frontend at a time
it is madness to require people to prevent 3
Bo Peng wrote:
Dear all,
Here is the promised patch. It is tested by
1. graphics seems to be converted correctly by convertDefault.py
2. by adding a converter from eps to ppm, a python script is generated
when I scroll userguide.lyx (use -dbg graphic to see it). The figure
is converted correctl
Dear all,
Here is the promised patch. It is tested by
1. graphics seems to be converted correctly by convertDefault.py
2. by adding a converter from eps to ppm, a python script is generated
when I scroll userguide.lyx (use -dbg graphic to see it). The figure
is converted correctly.
Please test.
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > You see... there is the difference, I don't plan on breaking the other
> | > frontends just because I am introducing a feature only for one of the
> | > frontends.
> | >
>
> [...]
> |
>
Am Sonntag, 25. Juni 2006 19:41 schrieb Juergen Spitzmueller:
> Very good, thanks. However, I think the "default" switches should be
disabled
> initially at least for non-booktabs tables. It looks rather odd for
those (on
> screen and output).
Only bottom_space makes sense for non booktab tabl
Lars Gullik Bjønnes wrote:
Ok, this is my final patch.
Please have a lookover of you have the time.
It looks fine. Please commit.
xforms is bonkers,
You're the specialist here ;-)
gtk somewhat works (no scrollbar though),
This should be easy to solve for a GTK hacker.
qt3 and
qt4 lo
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > You see... there is the difference, I don't plan on breaking the other
| > frontends just because I am introducing a feature only for one of the
| > frontends.
| >
[...]
|
| Now you write that you have an improvement but
Lars Gullik Bjønnes wrote:
> You see... there is the difference, I don't plan on breaking the other
> frontends just because I am introducing a feature only for one of the
> frontends.
>
> And this will be the case with unicode.
>
> (And if when I do/have done so, it has been a case of very bad
>
Georg Baum wrote:
> Am Montag, 12. Juni 2006 15:13 schrieb Juergen Spitzmueller:
> > I had a quick look. It looks good. However, it should be possible to use
> > \addlinespace (without optional argument). I guess most of the time
>
> you'll
>
> > need the same linespace, which is then globally defi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > I have created a GuiImplementation.C for gtk as well and then that
| > include should go there.
| > | | Index: GView.C
| > | ===
| > | --- GView.C
Lars Gullik Bjønnes wrote:
I have created a GuiImplementation.C for gtk as well and then that
include should go there.
|
| Index: GView.C
| ===
| --- GView.C (revision 14193)
| +++ GView.C (working copy)
| @@ -93,7 +93,6 @@
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | | Lars,
| > | | | | Could you please check in your changes to my branch so that
| > we can
| > | | merge the br
Hi *,
here is another patch I've found in the Debian LyX package you maybe
would like to apply to the LyX source tree.
In manpages all "-" should be escaped with "\-" to force a proper handling.
The attached patch has been created against the current 1.4.x branch.
Sven
--
If you won't forgive me
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Lars,
| |
| | Could you please check in your changes to my branch so that we can
| | merge the branch to trunk?
| | IMHO, I believe qt4 and qt3 are fully functional
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Lars,
| |
| | Could you please check in your changes to my branch so that we can
| | merge the branch to trunk?
| | IMHO, I believe qt4 and qt3 are fully functional now so even if xforms
| | and
I finally found the time to put together the promised patch.
I had to rename "cygwin_path_fix" as "windows_style_tex_paths" instead
of "posix_style_tex_paths" for compatibility reasons. Indeed, the
meaning of cygwin_path_fix was "the TeX engine expects windows paths".
Please, find attached the pat
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars,
|
| Could you please check in your changes to my branch so that we can
| merge the branch to trunk?
| IMHO, I believe qt4 and qt3 are fully functional now so even if xforms
| and gtk are not 100% functional we can fix that in trunk.
It would
Lars,
Could you please check in your changes to my branch so that we can merge
the branch to trunk?
IMHO, I believe qt4 and qt3 are fully functional now so even if xforms
and gtk are not 100% functional we can fix that in trunk.
I promise to revise my branch developing method afterward.
Abde
Michael Gerz <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| >Michael Gerz <[EMAIL PROTECTED]> writes:
| >
| >| Ask for xforms frontend removal - it is the easiest way to get things
| >| done :-)
| >
| >And to hide the performance we should be aiming for imho.
| >
| Lars,
|
| someti
Lars Gullik Bjønnes wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
| Ask for xforms frontend removal - it is the easiest way to get things
| done :-)
And to hide the performance we should be aiming for imho.
Lars,
sometimes it can become very tedious to discuss with you.
Are you aware o
Lars Gullik Bjønnes wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
| > -updateScrollbar();
| >+ //updateScrollbar();
| > }
| >
|
| Why don't you just remove the line? I don't like uncommented code as
| it is supposed to have some meaning. Are you uncertain about the code?
Yes.
Autho
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > Why don't you just remove the line? I don't like uncommented code as
| > it is supposed to have some meaning. Are you uncertain about the
| > code?
|
| I have removed the lines now.
Oh, I thought this was the line in the xforms code... which I am
I have to upgrade subversion to latest stable and since that is not
released as rpm for fc4 I have to do this manually. This means a short
downtime for the subversion service.
I'll try to be quick.
I'll send an update just before I take down the service.
--
Lgb
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
|
| | This patch even makes it run, albeit with a grabled screen. The gui
| | operations (adding objects and such) are done in the wrong order.
|
| No changes to xforms
Michael Gerz <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
|
| > This patch reduce the number of calls to
| > BufferView::updateScrollbar() to the bare minimum, that is in
| > GuiWorkArea::paintEvent(). All other calls are useless since we make
| > sure that the scrollbar is updated if a
Michael Gerz <[EMAIL PROTECTED]> writes:
| Ask for xforms frontend removal - it is the easiest way to get things
| done :-)
And to hide the performance we should be aiming for imho.
--
Lgb
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Agreed. That's why I am cleaning this GUI API... Or do you mean that I
| am doing bad at QoI?
Nope. No such thing implied.
--
Lgb
Michael Gerz wrote:
Abdelrazak Younes wrote:
and the other frontends are not portable.
xforms no, gtk maybe...
We really have to reconsider (again) the frontend issue.
- Why do we still have xforms? It won't survive the unicode patch anyway.
=> Let's remove it! Now!
- Has gtk ever wor
Michael Gerz wrote:
Abdelrazak Younes wrote:
This patch reduce the number of calls to BufferView::updateScrollbar()
to the bare minimum, that is in GuiWorkArea::paintEvent(). All other
calls are useless since we make sure that the scrollbar is updated if
and when anything is painted on screen
Abdelrazak Younes wrote:
This patch reduce the number of calls to BufferView::updateScrollbar()
to the bare minimum, that is in GuiWorkArea::paintEvent(). All other
calls are useless since we make sure that the scrollbar is updated if
and when anything is painted on screen.
Index: BufferView
Abdelrazak Younes wrote:
There are now two remaining uses of workArea_:
BufferView::Pimpl::update(Update::flags flags)
workArea_->redraw(*bv_, vi);
workArea_->greyOut();
These should be reasonably easy to solve but then I am affraid of the
work involved to fix the frontends other tha
Abdelrazak Younes wrote:
and the other frontends are not portable.
xforms no, gtk maybe...
We really have to reconsider (again) the frontend issue.
- Why do we still have xforms? It won't survive the unicode patch anyway.
=> Let's remove it! Now!
- Has gtk ever worked reliably? (Estima
Georg Baum wrote:
Edwin, could you please have a look at the qt4 problem? After that is
fixed the branch could be merged.
will do (saw the space problem too, but have been unable to trace down
the culprit...)
This fixes a wrong signal/slot connection and goes in now.
Georg
Log:
* src/frontends/qt4/QTabularDialog.[Ch]
(QTabularDialog::on_booktabsCB_stateChanged): remove int argument,
since the signal connected to this slot does not take an argument.
* src/frontends/qt4
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > However if I turn on USE_KEY_BUFFERING¹ it behaves properly,
| > updates
| > | > screen and stop when I release the button
| > | | This
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > However if I turn on USE_KEY_BUFFERING¹ it behaves properly,
| > updates
| > | > screen and stop when I release the button
| > | | This is interesting, do you confi
Am Montag, 12. Juni 2006 15:13 schrieb Juergen Spitzmueller:
> I had a quick look. It looks good. However, it should be possible to use
> \addlinespace (without optional argument). I guess most of the time
you'll
> need the same linespace, which is then globally defined.
This patch adds that.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > However if I turn on USE_KEY_BUFFERING¹ it behaves properly, updates
| > screen and stop when I release the button
|
| This is interesting, do you confirm me that with that macro turned off
| in trunk it works?
I ha
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > However if I turn on USE_KEY_BUFFERING¹ it behaves properly, updates
| > screen and stop when I release the button
|
| This is interesting, do you confirm me that with that macro turned off
| in trunk it works?
I have not verified that the macro
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | If I can achieve 16 seconds on my less powerful CPU, I reckon that,
| > | with a few X11 specific optimisation, you could achieve 8 second
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | If I can achieve 16 seconds on my less powerful CPU, I reckon that,
| > | with a few X11 specific optimisation, you could achieve 8 seconds and
| > | be on par with Ly
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > GuiWorkArea.C: In member function 'virtual void
| > lyx::frontend::GuiWorkArea::inputMethodEvent(QInputMethodEvent*)':
| > GuiWorkArea.C:606: error: 'class QInputMethodEvent' has no member n
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > GuiWorkArea.C: In member function 'virtual void
| > lyx::frontend::GuiWorkArea::inputMethodEvent(QInputMethodEvent*)':
| > GuiWorkArea.C:606: error: 'class QInputMethodEvent' has no member named
'text'
| >
| I've check
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If I can achieve 16 seconds on my less powerful CPU, I reckon that,
| with a few X11 specific optimisation, you could achieve 8 seconds and
| be on par with LyX/xforms.
|
| > The tests might however not be entirely fair
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If I can achieve 16 seconds on my less powerful CPU, I reckon that,
| with a few X11 specific optimisation, you could achieve 8 seconds and
| be on par with LyX/xforms.
|
| > The tests might however not be entirely fair since xforms is quite bad
| >
Lars Gullik Bjønnes wrote:
GuiWorkArea.C: In member function 'virtual void
lyx::frontend::GuiWorkArea::inputMethodEvent(QInputMethodEvent*)':
GuiWorkArea.C:606: error: 'class QInputMethodEvent' has no member named 'text'
I've checked in a fix:
GuiWorkArea::inputMethodEvent():
In Qt4.1.4, QIn
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jose' Matos wrote:
| > Hi,
| > this is another subjective report so please take it with a grain of salt.
:-)
| > I have updated qt4 to the latest 4.1.4 and I perceive it as
| > faster, I can certainly notice the differ
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | This patch makes it compile (and probably breaks qt), but xforms
| > fails
| > | brutally upon start up.
| > This patch even makes it ru
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jose' Matos wrote:
| > OK, trying to compile your branch for qt4 only I get two errors:
| >
| > Application.C: In member function 'virtual bool
| > lyx::frontend::Application::x11EventFilter(XEvent*)':
| > Applicatio
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] writes:
| Author: younes
| Date: Sun Jun 25 13:23:53 2006
| New Revision: 14202
|
| Log:
| Compilation Fix: WorkArea has no view() member anymore. Application needed a BufferView anyway so I replaced
| void setBufferView(BufferView * buffer_view);
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jose' Matos wrote:
| > OK, trying to compile your branch for qt4 only I get two errors:
| >
| > Application.C: In member function 'virtual bool
| > lyx::frontend::Application::x11EventFilter(XEvent*)':
| > Application.C:77: error: 'class lyx::fr
Am Sonntag, 25. Juni 2006 06:31 schrieb Bo Peng:
> Hi,
>
> Attached is our long-waited patch that replaces sh by python so that
> lyx/win does not have to be bundled with sh, sed etc. I plan to test
> and apply this patch (without changes to configure.py) and then
> translate shell scripts in lib/
[EMAIL PROTECTED] writes:
| Author: younes
| Date: Sun Jun 25 13:23:53 2006
| New Revision: 14202
|
| Log:
| Compilation Fix: WorkArea has no view() member anymore. Application needed a
BufferView anyway so I replaced
| void setBufferView(BufferView * buffer_view);
| with
| void connect(Gui
Jose' Matos wrote:
OK, trying to compile your branch for qt4 only I get two errors:
Application.C: In member function 'virtual bool
lyx::frontend::Application::x11EventFilter(XEvent*)':
Application.C:77: error: 'class lyx::frontend::GuiWorkArea' has no member
named 'view'
Application.C:82
Abdelrazak Younes wrote:
Ah? Then it's better to stay with the reset solution. Please commit your
patch.
it's in
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Hum maybe instead of doing that we could as well reuse the same
QPainter and call QPainter::begin() instead:
we would still need to reset the cache since:
"Notice that all painter settings (setPen(), setBrush() etc.) are reset
to default values wh
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | This patch makes it compile (and probably breaks qt), but xforms
| > fails
| > | brutally upon start up.
| > This patch even makes it run, albeit with a grabled scre
Abdelrazak Younes wrote:
Hum maybe instead of doing that we could as well reuse the same QPainter
and call QPainter::begin() instead:
we would still need to reset the cache since:
"Notice that all painter settings (setPen(), setBrush() etc.) are reset
to default values when begin() is called.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Why is the assert commented out?
| > @@ -1949,8 +1948,8 @@
| > BufferView * LyXFunc::view() const
| > {
| > - BOOST_ASSERT(owner);
| > - return owner->view().get();
| > +//
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jose' Matos wrote:
| > Hi,
| > this is another subjective report so please take it with a grain of
salt. :-)
| > I have updated qt4 to the latest 4.1.4 and I perceive it as
| > faster, I can certainly notice the difference from the first ver
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I've tested it and it works fine so I've committed it.
i need to reset the cached color/ls/lw in start() when a new QPainter is
created
Hum maybe instead of doing that we could as well reuse the same QPainter
and call QPainter::begin() instead:
Bo Peng wrote:
Hi,
Attached is our long-waited patch that replaces sh by python so that
lyx/win does not have to be bundled with sh, sed etc. I plan to test
and apply this patch (without changes to configure.py) and then
translate shell scripts in lib/scripts one by one (and change
configure.py
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| This patch even makes it run, albeit with a grabled screen. The gui
| operations (adding objects and such) are done in the wrong order.
No changes to xforms, but changes so that qt compiles.
(patch at bottom)
Qt4 and
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| This patch makes it compile (and probably breaks qt), but xforms fails
| brutally upon start up.
This patch even makes it run, albeit with a grabled screen. The gui
operations (adding objects and such) are done in the
Abdelrazak Younes wrote:
I've tested it and it works fine so I've committed it.
i need to reset the cached color/ls/lw in start() when a new QPainter is
created
patch attached (also got rid of the QPainter arg in setQPainterPen(...))
Index: src/frontends/qt4/QLPainter.C
===
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
|
| | This patch even makes it run, albeit with a grabled screen. The gui
| | operations (adding objects and such) are done in the wrong order.
|
| No changes to xforms, but changes so that qt compi
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
Why this change?
For consistency reason with other macros. I don't care much.
-#ifndef GUIVIEW_H
-#define GUIVIEW_H
+#ifndef GUI_VIEW_H
+#define GUI_VIEW_H
If to make the string unique, I would have prefered: QT4_GU
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
Index: src/frontends/qt3/QtView.h
===
--- src/frontends/qt3/QtView.h
(.../svn+ssh://svn.lyx.org/lyx/lyx-devel/trunk/s
rc) (revision 14200)
+++ src/fronte
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Why is the assert commented out?
| > @@ -1949,8 +1948,8 @@
| > BufferView * LyXFunc::view() const
| > {
| > - BOOST_ASSERT(owner);
| > - return owner->view().get();
| > +// BOOST_ASSERT(owner);
| > +
Lars Gullik Bjønnes wrote:
Why is the assert commented out?
@@ -1949,8 +1948,8 @@
BufferView * LyXFunc::view() const
{
- BOOST_ASSERT(owner);
- return owner->view().get();
+// BOOST_ASSERT(owner);
+ return owner->view();
IIRC correctly this was because it was accessed
Jose' Matos wrote:
OK, trying to compile your branch for qt4 only I get two errors:
I will fix that. Thanks for the report.
Abdel.
Application.C: In member function 'virtual bool
lyx::frontend::Application::x11EventFilter(XEvent*)':
Application.C:77: error: 'class lyx::frontend::GuiW
Jose' Matos wrote:
Hi,
this is another subjective report so please take it with a grain of
salt. :-)
I have updated qt4 to the latest 4.1.4 and I perceive it as faster, I can
certainly notice the difference from the first version I tried (4.1.2).
FWIW I have lyx configure wi
78 matches
Mail list logo
