Jiba wrote:
Hi,
I'm currently working on packaging LyX 1.4.5.1 for Zaurus (Cacko ROM, IPKG),
and, using the XForms frontend, I get surprising low performance, in particular
when typing text very quickly.
I investigate the problem, and it appears that, for each character typed, LyX
r
Hi,
I'm currently working on packaging LyX 1.4.5.1 for Zaurus (Cacko ROM, IPKG),
and, using the XForms frontend, I get surprising low performance, in particular
when typing text very quickly.
I investigate the problem, and it appears that, for each character typed, LyX
re-set the pixm
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
(snip)
> Concerning this bug in particular, I do not think that this bug has
> anything to do with xforms. Actually I have seen things like that when
> using page-up in documents containing tables.
(snip)
I think I've managed
> "Sven" == Sven Hoexter <[EMAIL PROTECTED]> writes:
>> BTW, how comes that lyx on debian triggers assertions? Do you keep
>> them on intentionally?
Sven> s/intentionally/historically/ would be the better term. As far
Sven> as I can travel back in our svn they've been always enabled.
Sven> Th
On Wed, Oct 18, 2006 at 09:54:30AM +0200, Jean-Marc Lasgouttes wrote:
Hi,
> BTW, how comes that lyx on debian triggers assertions? Do you keep them
> on intentionally?
s/intentionally/historically/ would be the better term. As far as I can travel
back in our svn they've been always enabled. They'
>>>>> "Sven" == Sven Hoexter <[EMAIL PROTECTED]> writes:
Sven> On Tue, Oct 17, 2006 at 07:33:40PM -0400, Mark Carroll wrote:
Sven> Hello Mark, hello *, I'm not sure if there is still someone
Sven> interested in fixing bugs in the xforms frontend. I
Am Mittwoch, 18. Oktober 2006 08:50 schrieb Sven Hoexter:
> On Tue, Oct 17, 2006 at 07:33:40PM -0400, Mark Carroll wrote:
>
> Hello Mark, hello *,
> I'm not sure if there is still someone interested in fixing bugs in the
> xforms frontend. I'd suggest you to try out the
On Tue, Oct 17, 2006 at 07:33:40PM -0400, Mark Carroll wrote:
Hello Mark, hello *,
I'm not sure if there is still someone interested in fixing bugs in the
xforms frontend. I'd suggest you to try out the qt frontend by installing
the lyx-qt package.
Moreover I'm forwarding this
msgid =~ m/\|[^ ]/ ) != ( $msgstr =~ m/\|[^ ]/ ) ) {
- print( "Missing or unexpected xforms shortcut:\n" );
- print( " '$msgid' => '$msgstr'\n" );
- $warn++;
-}
-
We still use this form for menus. Shouldn't we test for i
Abdelrazak Younes wrote:
Could you fix also what's below while you're at it?
Done.
Michael
+ Or:
+ * The Qt4 library, version 4.1.1 or newer.
+Possible values: qt, qt4, gtk(EXPERIMENTAL)],
Michael Gerz <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
|
| >On Mon, Jul 10, 2006 at 09:39:39PM +0200, Michael Gerz wrote:
| >
| >>Subject says it all.
| >>
| >>Michael
| >>
| >>Index: SConstruct
| >>===
| >>--- SConstruct (
Andre Poenitz wrote:
On Mon, Jul 10, 2006 at 09:39:39PM +0200, Michael Gerz wrote:
Subject says it all.
Michael
Index: SConstruct
===
--- SConstruct (Revision 14416)
+++ SConstruct (Arbeitskopie)
@@ -122,7 +122,7 @@
opts.Add
> -allowed_values = ('xform', 'qt2', 'qt3', 'qt4', 'gtk') ),
> +allowed_values = ('qt2', 'qt3', 'qt4', 'gtk') ),
qt2 looks odd.
Unless you want to rename src/frontends/qt2 in the 1.4.x branch to
qt3. The existence of that directory, by the way, is a signature for
scons to tell 1
On Tuesday 11 July 2006 18:22, Andre Poenitz wrote:
> qt2 looks odd.
And it is wrong for 1.5.x, I only support qt3+ there.
> Andre'
--
José Abílio
On Mon, Jul 10, 2006 at 09:39:39PM +0200, Michael Gerz wrote:
> Subject says it all.
>
> Michael
>
> Index: SConstruct
> ===
> --- SConstruct (Revision 14416)
> +++ SConstruct (Arbeitskopie)
> @@ -122,7 +122,7 @@
> opts.AddOptions(
>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Hi, here are a few more files that had references to xforms.
Michael, I am a bit late, but the following seems dubious to me:
--- po/pocheck.pl (Revision 14371)
+++ po/pocheck.pl
Michael Gerz writes:
> I think this code can be removed. Any comments?
I think you're right.
A.
g const & title) const;
- /// redraw widgets (for xforms color change)
- void redrawGUI();
-
/// set a color
void setColor(LColor_color col, std::string const & hex);
27;mode', 'Building method', default_build_mode,
allowed_values = ('debug', 'release') ),
@@ -366,10 +366,6 @@
# PACKAGE_VERSION
# src/version.C.in
# PACKAGE_VERSION, VERSION_INFO
-# src/frontends/xforms/lyx_xpm.h.in
-# XPM_H_LOCATION
-# src/frontends/xforms/lyx_forms.h.in
-# FORMS_H_LOCATION
# full path name is used to build msvs project files
# and to replace TOP_SRCDIR in package.C
Georg Baum wrote:
Michael,
you forgot the frontend for the rpm spec file. The attached goes in now.
Thanks, Georg!
Michael
Lars Gullik Bjønnes wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
| -### Check which frontends we want to use. The default is XForms only
| +### Check which frontends we want to use.
| ###
| AC_DEFUN([LYX_USE_FRONTENDS],
| [AC_MSG_CHECKING([what frontend should be used for t
Michael Gerz <[EMAIL PROTECTED]> writes:
| -### Check which frontends we want to use. The default is XForms only
| +### Check which frontends we want to use.
| ###
| AC_DEFUN([LYX_USE_FRONTENDS],
| [AC_MSG_CHECKING([what frontend should be used for the GUI])
| AC_ARG_WITH(fr
Am Samstag, 8. Juli 2006 13:10 schrieb Michael Gerz:
> Hi,
>
> some more xforms relicts, use --with-frontend=qt3
Michael,
you forgot the frontend for the rpm spec file. The attached goes in now.
Georg
Index: con
Hi,
some more xforms relicts, use --with-frontend=qt3
Michael
Index: configure.ac
===
--- configure.ac (Revision 14371)
+++ configure.ac (Arbeitskopie)
@@ -180,7 +180,7 @@
libglademm version:\t\t${LIBGLADEMM_VERSION}\n
Hi,
here are a few more files that had references to xforms.
I am committing right now, as the changes look rather trivial.
Michael
Index: src/frontends/qt3/QPrefs.C
===
--- src/frontends/qt3/QPrefs.C (Revision 14371)
+++ src
>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Hi, this patch removes a few references to the xforms
Michael> frontend. In particular, it removes ControlPreamble.[Ch]
Michael> which was only used by the xforms frontend (see comment
Michael Gerz wrote:
Hi,
this patch removes a few references to the xforms frontend. In
particular, it removes ControlPreamble.[Ch] which was only used by the
xforms frontend (see comment inside of the file).
Ok to commit?
Could you fix also what's below while you're at it?
Michael Gerz <[EMAIL PROTECTED]> writes:
| Hi,
|
| this patch removes a few references to the xforms frontend. In
| particular, it removes ControlPreamble.[Ch] which was only used by the
| xforms frontend (see comment inside of the file).
|
| Ok to commit?
Certainly.
--
Lgb
Hi,
this patch removes a few references to the xforms frontend. In
particular, it removes ControlPreamble.[Ch] which was only used by the
xforms frontend (see comment inside of the file).
Ok to commit?
Michael
Index: src/PrinterParams.h
On Sun, Jul 02, 2006 at 10:22:45PM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | Talking about xforms, how far ahead is your Unicode patch?
>
> Writing and reading files work, inseting work. All
> control keys crash LyX instantly
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > I have not fixed scons
|
| Scons does not support xforms.
Still it is mentioned in its files.
--
Lgb
I have not fixed scons
Scons does not support xforms.
Bo
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Michael Gerz <[EMAIL PROTECTED]> writes:
|
| | Andre Poenitz wrote:
| |
| | >This removes the source files and everything I could identify as
| | >belonging to xforms in the autoconf machinery.
| | >
| | >I do not know what to
Michael Gerz <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
|
| >This removes the source files and everything I could identify as
| >belonging to xforms in the autoconf machinery.
| >
| >I do not know what to do with po/*. Am I right in assuming that stuff in
| >
Andre Poenitz wrote:
This removes the source files and everything I could identify as
belonging to xforms in the autoconf machinery.
I do not know what to do with po/*. Am I right in assuming that stuff in
there will get fixed automatically?
At least the *.po files will be cleaned after the
On Sun, Jul 02, 2006 at 09:13:44PM +0200, Lars Gullik Bjønnes wrote:
>
> Since this sees to be the one of the main things we have heated
> debates on, we might as well get rid of it. I still have some
> reservations, but it is not as if I am ever going to use xforms
> myself.
>
Georg Baum wrote:
The wiki will not work, that is too complicated. I think the best thing
would be to put some FIXME comments directly in the gtk source code,
because that is less work for everybody.
or a FIXME file in the gtk root...
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Actually I have had this planned for a while... just wanted major
| > branches merged first... (My xml branch will have a problem with this
| > though... or is svn merge clever enought to handle this?)
|
| Please wait for
Edwin Leuven wrote:
> the 3rd step would be to follow john spray's suggestion, and keep track
> of backend changes that affect gtk on the wiki or another appropriate
> place
The wiki will not work, that is too complicated. I think the best thing
would be to put some FIXME comments directly in the
Lars Gullik Bjønnes wrote:
> Actually I have had this planned for a while... just wanted major
> branches merged first... (My xml branch will have a problem with this
> though... or is svn merge clever enought to handle this?)
Please wait for the booktabs merge. Unfortunately I am not sure whethe
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Writing and reading files work, inseting work. All
| > control keys crash LyX instantly... remember I asked for help?
|
| If major coding has been done and you just need to make everything
| work as usual, I would suggest that you merge your branch to th
Hi, Lar,
I am really happy about your decision regarding xforms and gtk. This
will make everyone's life easier.
| Talking about xforms, how far ahead is your Unicode patch?
Writing and reading files work, inseting work. All
control keys crash LyX instantly... remember I asked for help?
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Talking about xforms, how far ahead is your Unicode patch?
Writing and reading files work, inseting work. All
control keys crash LyX instantly... remember I asked for help?
And I need something like the any patch in...
| About gtk, I go
very clear that he is the only person doing anything with gtk, and
> that he is time limited.
Talking about xforms, how far ahead is your Unicode patch?
About gtk, I got this beautiful new Nokia 770. I might get interested in
getting LyX to run on it (which would mean gtk2). If I could find the
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This removes the source files and everything I could identify as
| belonging to xforms in the autoconf machinery.
|
| I do not know what to do with po/*. Am I right in assuming that stuff in
| there will get fixed automatically?
Not quite. But
Edwin Leuven <[EMAIL PROTECTED]> writes:
| the 3rd step would be to follow john spray's suggestion, and keep
| track of backend changes that affect gtk on the wiki or another
| appropriate place
I'll even take this one further... as long as there seems to be no
active gtk developers we should do
Lars Gullik Bjønnes wrote:
Since this sees to be the one of the main things we have heated
debates on, we might as well get rid of it. I still have some
reservations, but it is not as if I am ever going to use xforms
myself.
So unless I get objections, I will remove XForms from trunk tomorrow
Since this sees to be the one of the main things we have heated
debates on, we might as well get rid of it. I still have some
reservations, but it is not as if I am ever going to use xforms
myself.
So unless I get objections, I will remove XForms from trunk tomorrow
evening. (Almost a bit sad
xforms, but changes so that qt compiles.
| (patch at bottom)
But also qt3 segfaults upon startup:
The following committed patch should solve this crash. I believe
something similar should be done for gtk.
Abdel.
Log:
Fix qt3 crash by delaying QtView member object initialisation as done in
the
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:
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:
| 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.
| > Thi
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,
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
[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
[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 gtk has some failures
[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 wrong order.
Index: src
This patch makes it compile (and probably breaks qt), but xforms fails
brutally upon start up.
IMHO there are too many different changes in the younes branch now.
Index: src/frontends/WorkArea.h
===
--- src/frontends/WorkArea.h
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > | | I am doing that right now... difficult.
| > | > No it is dead easy if you
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | I am doing that right now... difficult.
| > No it is dead easy if you followe the 3 step rebase procedure that I
| > have posted ealier.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | | I am doing that right now... difficult.
| > No it is dead easy if you followe the 3 step rebase procedure that I
| > have posted ealier.
|
| Svn rebase is dead easy
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| I am doing that right now... difficult.
No it is dead easy if you followe the 3 step rebase procedure that I
have posted ealier.
Svn rebase is dead easy with my procedure also. The problem was in the
conflict betwe
t; It also update th scrollbar in the QContent::paintEvent(). I still
| > | > have to read the Qt3 doc to see how to disable tracking in the
| > | > scrollbar.
| > | > Once the qt3 support is in and works, it should be reasonably easy
| > | > to complete the xforms and gtk fr
ad the Qt3 doc to see how to disable tracking in the
| > scrollbar.
| > Once the qt3 support is in and works, it should be reasonably easy
| > to complete the xforms and gtk frontend also.
|
| The qt3 support is in and it works fine, the code for scrollbar
| tracking for qt4 turned out
w to disable tracking in the
| > scrollbar.
| > Once the qt3 support is in and works, it should be reasonably easy
| > to complete the xforms and gtk frontend also.
|
| The qt3 support is in and it works fine, the code for scrollbar
| tracking for qt4 turned out to be the same for qt3 :-).
|
should be reasonably easy to
complete the xforms and gtk frontend also.
The qt3 support is in and it works fine, the code for scrollbar tracking
for qt4 turned out to be the same for qt3 :-).
Here is preliminar support for gtk and xforms. Don't know if it compiles
but it goes in "yo
eration
> View: virtual interface for Views
> WorkArea: virtual interface for WorkAreas
> Clipboard: virtual interface for clipboard operation
> GuiCursor: this one is special because it does not need a frontend
> specialisation.
> in src/frontends/[qt3,qt4,gtk,xforms]
On Thu, Jun 15, 2006 at 11:43:26AM +0200, Abdelrazak Younes wrote:
> I didn't feel like changing the namespace everywhere so instead I just
> put everything in lyx::frontend. We could still do the change afterward
> if we feel it is needed.
I like the 'flatter' version (lyx::frontend vs lyx::fro
Georg Baum wrote:
Am Donnerstag, 15. Juni 2006 19:30 schrieb Abdelrazak Younes:
Do you have access to my branch or shall I commit for you?
I committed it.
Thanks.
Abdel.
Am Donnerstag, 15. Juni 2006 19:30 schrieb Abdelrazak Younes:
> And it compiles with your patch right?
Yes.
> Yes, it's amazing how many things I missed! I went through gtk and
> xforms and I could have swear that I have done the things you've done...
> Anyway, thanks (a
uot; branch now. Tested for qt3 and qt4.
qt4 does not compile on X11 and Mac (no WorkArea::view()),
And it compiles with your patch right?
qt3 does not
link and and gtk and xforms have compile errors too. Is the attached what
you intended?
Yes, it's amazing how many things I missed! I
s" branch now. Tested for qt3 and qt4.
qt4 does not compile on X11 and Mac (no WorkArea::view()), qt3 does not
link and and gtk and xforms have compile errors too. Is the attached what
you intended?
Georg
Index: src/frontends/gtk/GScreen.C
=
WorkAreas
Clipboard: virtual interface for clipboard operation
GuiCursor: this one is special because it does not need a frontend
specialisation.
in src/frontends/[qt3,qt4,gtk,xforms]/: in the respective namespace we
have lyx::frontend::[qt3,qt4,gtk,xforms]::
TheGui, GuiView, G
Andre Poenitz wrote:
> Angus Leeming wrote:
>> Why not have namespaces to reflect the directory
>> structure?
>> lyx
>> lyx::frontends
>> lyx::frontends::qt4
>> lyx::support
> Well, maybe better than what we have now, but having
> classes of the same
> name only distinguished by namespace is stil
On Mon, Jun 12, 2006 at 10:11:27PM +0200, Georg Baum wrote:
> - The existence of lyx::WorkArea and lyx::frontend::WorkArea does seems to
> confuse compilers.
And humans. I think it's generally a bad idea to have classes only
distinguished by namespace.
Andre'
On Tue, Jun 13, 2006 at 11:36:09AM +0100, Angus Leeming wrote:
> Why not have namespaces to reflect the directory
> structure?
>
> lyx
> lyx::frontends
> lyx::frontends::qt4
> lyx::support
Well, maybe better than what we have now, but having classes of the same
name only distinguished by namespac
Angus Leeming wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
I think they are at a good place in
frontends/ but I agree that the lyx
namespace is wrong. What about a new
namespace in order to avoid
confusion? Multiple possibilities:
- gui
- gui_interface
- interfac
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>> I think they are at a good place in
>>> frontends/ but I agree that the lyx
>>> namespace is wrong. What about a new
>>> namespace in order to avoid
>>> confusion? Multiple possibilities:
>>> - gui
>>> - gui_interface
>>>
Peter Kümmel wrote:
Georg Baum wrote:
One of the tricks used earlier was to make sure that
was included before the qt headers.
But it is! is included in LyXView.h which is the
second include in QtView.h (after config.h), which is the second include
in QCommandBuffer.C (after config.h).
I
Georg Baum wrote:
Abdelrazak Younes wrote:
I think they are at a good place in frontends/ but I agree that the lyx
namespace is wrong. What about a new namespace in order to avoid
confusion? Multiple possibilities:
- gui
- gui_interface
- interface
- ui
- ui_communication
...
I'd prefer gui,
Abdelrazak Younes wrote:
> I think they are at a good place in frontends/ but I agree that the lyx
> namespace is wrong. What about a new namespace in order to avoid
> confusion? Multiple possibilities:
> - gui
> - gui_interface
> - interface
> - ui
> - ui_communication
> ...
I'd prefer gui, but
e the only
potential problem could be in compiling the frontend.
Why should tgere be a problem?
I mean if you don't respect the rule and if frontends/ is in the include
path.
No, no, all your changes seem very reasonable. Please apply. So with the
patch, qt3, xforms and gtk performs like
in. I am really happy that you give me a hand
> here. It's weird though that I don't need the additional includes in
> "BufferView_pimpl.C".
They are needed because I removed them from Gui.h.
> No, no, all your changes seem very reasonable. Please apply. So with the
> patch, qt3, xforms and gtk performs like usual?
I don't know, I only compiled and did not test. BTW I won't be able to apply
during the next two days.
Georg
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > - It is confusing that src/frontends/Gui.h defines lyx::Gui, and
| > src/frontends/qt3/Gui.h defines lyx::frontend::Gui.
|
| But I asked multiple time if anyone had any objection (you also said
| that it was fine with
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > - It is confusing that src/frontends/Gui.h defines lyx::Gui, and
| > src/frontends/qt3/Gui.h defines lyx::frontend::Gui.
|
| But I asked multiple time if anyone had any objection (you also said
| that it was fine with you ;-)).
At lest to me it w
really happy that you give me a hand
here. It's weird though that I don't need the additional includes in
"BufferView_pimpl.C".
If you don't like that you should rethink your decision
to have the contens of these classes not in class Gui.
No, no, all your changes s
Georg Baum wrote:
>>> One of the tricks used earlier was to make sure that
>>> was included before the qt headers.
>> But it is! is included in LyXView.h which is the
>> second include in QtView.h (after config.h), which is the second include
>> in QCommandBuffer.C (after config.h).
>>
>>> I du
Arbeitskopie)
@@ -82,7 +82,6 @@ libqt4_la_SOURCES = \
Qt2BC.C Qt2BC.h \
QtLyXView.h \
checkedwidgets.C checkedwidgets.h \
- LyxClipboard.C LyxClipboard.h \
Application.C Application.h \
lyx_gui.C \
lcolorcache.h lcolorcache.C \
Index: src/frontends/Gui.h
===
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Abdelrazak Younes wrote:
| > | > Hello,
| > | > I just committed this patch the "younes" branch. I would be happy if
| > | > some kind sou
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Abdelrazak Younes wrote:
| > | > Hello,
| > | > I just committed this patch the "younes" branch. I would be happy if
| > | > some kind sould help me verify complete th
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Hello,
| > I just committed this patch the "younes" branch. I would be happy if
| > some kind sould help me verify complete that.
|
| I managed to install Qt3 so I have fixed compilation issu
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Hello,
| > I just committed this patch the "younes" branch. I would be happy if
| > some kind sould help me verify complete that.
|
| I managed to install Qt3 so I have fixed compilation issues for qt3. I
| have a new we
Abdelrazak Younes wrote:
Hello,
I just committed this patch the "younes" branch. I would be happy if
some kind sould help me verify complete that.
I managed to install Qt3 so I have fixed compilation issues for qt3. I
have a new weird issue though:
D:\devel\lyx\trunk\src\frontends\qt3\QCom
Hello,
I just committed this patch the "younes" branch. I would be happy if
some kind sould help me verify complete that.
Next step: Makefile.am updates.
Thanks,
Abdel.
Log:
qt3, gtk, xforms preliminar support for new GUI API.
This patch encapsulate the old API into the new
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>> I think he means shouldn't the second be poxy instead of posx?
>> Of course that is wrong. Could you please fix it?
Abdelrazak> Done.
Doh! Thanks.
JMarc
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I mean it uses both times posx, shouldn't be the second one
Peter> posy?
It was indeed a bug, and I failed to understand what you meant.
Thanks.
JMarc
Georg Baum wrote:
Abdelrazak Younes wrote:
I think he means shouldn't the second be poxy instead of posx?
Of course that is wrong. Could you please fix it?
Done.
Abdel.
Georg
Abdelrazak Younes wrote:
> I think he means shouldn't the second be poxy instead of posx?
Of course that is wrong. Could you please fix it?
Georg
1 - 100 of 1731 matches
Mail list logo