current CVS does not compile with KDE frontend due to the difference in
Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs
class constructor expects LyXView* as its argument in Xforms frontend
(src/frontends/Dialogs.h src/frontends/xforms/Dialogs.C) and LyXFunc* as
an
all development has been done with the xforms code. The code in the kde
directory was written as proof of concept a long, long time ago. As such, it
has lagged behind...
You are correct to report that the code in kde/Dialogs.C is inconsistent with
that in xforms/Dialogs.C. It is wrong and
I've tried to add some elementary support of GTK/Gnome frontend to LyX.
The composed code and collection of configure .m4 scripts brings the GTK
frontend to the same level as KDE one --- showing the copyright dialog
box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK
and
On Tue, 11 Jul 2000, Lars Gullik Bjønnes wrote:
| 2. Make LyX compatible with the string class included in libstdc++ by
| fixing files src/support/lstrings.C (lines 184 and 201,
| string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string
| interaction).
You mean unfixing I
Hi!
the attached patch together with additional files included into the
.tar.gz archive adds elementary support for GTK/Gnome frontend: configure
scripts, Gtk/Gnome initialization, Gnome event loop processing, and
Copyright dialog box implementation.
It should be easy to use this code on the
Hi,
It seems that we miss an .m4 file which defines AM_PATH_GTK (and
probably others). It is now impossible for me to compile for xforms,
since the configure file produced by autoconf is plain wrong...
I've obtained a fresh copy of lyx-devel this morning (cvs checkout) and at
least xforms
I do have all this files, but I think you have some gtkxxx.m4 files in
your /usr/share/aclocal (or whereever) directory, that got installed
when installing gtk. A simple check: grep AM_PATH_GTK
config/gnome/*.m4 reveals that this macro is used there, but never
defined.
I see! The attached
We certinly need the AC_LANG_CPLUSPLUS, since otherwise checks for the
C++ compilers features are done with the C compiler :) I put it back
in, and added an AC_LANG_CPLUS_PLUS later.
In general, configuring with AC_LANG_CPLUS_PLUS would be better, since
we will compile with the C++
Could you show us this small program? It might be that it uses a
valid C syntax that is not valid C++. These things are easy to fix in
general.
I mean the program used inside the script (gtk.m4) for checking GTK
libraries installation.
Marko
On 25 Jul 2000, Jean-Marc Lasgouttes wrote:
Yes, I understand. But which one is it? And what is the error message
in config.log?
I've checked out the latest version from cvs and everything worked fine!
GTK, gnome, gtkmm, gnomemm were configured without any errors. Thus, it is
hard for me to
On 25 Jul 2000, Jean-Marc Lasgouttes wrote:
Yes, you should comment out the AC_LANG_C at line 89 of configure.in.
AC_TRY_RUN compiles gtk program with C++ compiler instead of C compiler.
That's why environment variable CFLAGS doesn't have any effect (see line
58, file
On Tue, 25 Jul 2000, Juergen Vigna wrote:
Well I guess that gtk is a ONLY C library and so does not compile with
a c++ compiler (only a guess but I already had such problems on linking!)
Why don't you test only for gtk-- as you need that one?
That's a good point. We can use gtk--/gnome--
On Wed, 26 Jul 2000, Juergen Vigna wrote:
On 26-Jul-2000 Jean-Marc Lasgouttes wrote:
I think we should try the pure C++ route and remove the rest for now.
Therefore, we'll have to think twice before using the C functions
directly (or force the foo-- people to improve their support).
On Wed, 26 Jul 2000, Juergen Vigna wrote:
I thought too that you don't need to add the --without-included-string but if
you don't the compilation aborts on lyx_gui.C with some strange error-message
from LString.h that someone is included in the wrong order (I lost the whole
message on the
On 26 Jul 2000, Jean-Marc Lasgouttes wrote:
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen BTW.: This now is in cvs and working it seems, now Marko has
Juergen just to provide the Menubar and Toolbar pimpl files
Juergen (otherwise they have to be linked in from the xforms
Hi!
this patch adds Gnome/Gtk menu to LyX. Since menu is a part of Gnome
application main window, a small main window class (GLyxAppWin) is added
too. Eventually, when LyXView will be ported to Gnome or LyX main window
will be GUI independent, GLyxAppWin will be replaced. Thus, when compiled
On Wed, 9 Aug 2000, Juergen Vigna wrote:
Applied will commit soon (just let me test it ;)
You need to set up two symbolic links to compilelink it:
src/frontends/gnome/Toolbar_pimpl.[Ch]--src/frontends/xforms/Toolbar_pimpl.[Ch]
Marko
On Wed, 9 Aug 2000, Juergen Vigna wrote:
Well my first impression is it works ;), it is VERY slow on update, but
probably you will solve this. IMO as first work it looks good #:O), let's
see how the toolbar works then ;)
I think it is slow due to XForms event handler. To make it fast one
On Wed, 9 Aug 2000, Juergen Vigna wrote:
1. For Marko (and mybe other people who want to support another frontend):
The Menu_pimpl you did is nice but as you surely have seen there are
some bases which do not work and so the whole menu-stuff is really not
good working. IMO you
On Wed, 9 Aug 2000, Juergen Vigna wrote:
Then you could help us with hints for what you need f.ex. in LyXView so
that you really can use the GNOME-menus or/and toolbars when you make that
one work.
I've took a first look into toolbar implementation and I am wondering why
this
Hi!
the following patch together with additional files in tar.gz archive add
Print and InsertUrl dialogs to Gnome frontend.
The dialogs were implemented using Glade and its C output. I've tried to
use glade-- to produce C++ output , but the result was far from complete
since glade-- doesn't
On Mon, 14 Aug 2000, Juergen Vigna wrote:
On 13-Aug-2000 Tuukka Toivonen wrote:
Sorry to interfere... but I'd love to have GTK LyX without required to
install Gnome. Would it be too much trouble supporting GTK without Gnome
too?
You need to install Gnome libraries only, not complete
On Mon, 14 Aug 2000, Allan Rae wrote:
On Mon, 14 Aug 2000, Marko Vendelin wrote:
The dialogs were implemented using Glade and its C output. I've tried to
use glade-- to produce C++ output , but the result was far from complete
since glade-- doesn't cover Gnome very well and produces
Hi!
this patch ports two more dialogs to Gnome frontend. I've also included
all glade project files that were used for all ported dialogs. It would be
nice to have these files in CVS too.
The patch fixes some small bugs in Gnome GUIRunTime_pimpl.C (we still have
to include FORMS_H_LOCATION to
On Thu, 17 Aug 2000, Juergen Vigna wrote:
I had a look at the patch and the files and have some more comments ;)
- I've seen that the *callbacks.c files are just empty containers and IMO
they should be removed as they are not needed.
not all are empty (diaprint_callbacks.c). Well, the
On Fri, 18 Aug 2000, Juergen Vigna wrote:
I guess the callbacks should go into the FormXxx files and so we can
remove this additional files and yes we have to postprocess the .[ch]
files I've seen that already, so if you move the callbacks you use into
the FormXxx implementation I see then
I think that the problem is in the way LyX calls "update" function. For
example, when I press "Undo" in the menu, the "Redo" command is still
disabled. I have to move and click mouse in LyX working area to get it
enabled. I would predict, that the toolbar should have the similar
behavior.
If it's always identical we could just modify it and leave it there as a
class helper function.
true
Well I tracked this down till LyXView::showState which updates the right
things and the toolbar than is updated. If showState is not called there
is no update at all! IMO there has some
On Fri, 18 Aug 2000, Juergen Vigna wrote:
Well, I can't reproduce it (or I don't undestand how I can get into this
"tabular" thing :) ). However, if you know any LyX action which changes
its state after you enter tabular from "plain action" to action which can
be toggled
Hi!
before porting these dialogs to gnome frontend I would like to ask the
following questions:
FormCitation: I think that there is an important functionality missing in
this dialog. Namely, I really miss "Search" and bibtex parser. In my work,
I use bibtex database which has more than 1000
On Thu, 17 Aug 2000, Juergen Vigna wrote:
- I had a look at Menubar_pimpl.C and have seen the composeUI function in
which you search for some commands to probably use some standard, GNOME
menu items for them, but why to you use the command-string and not directly
the action-int
ping does nothing,
traceroute to aussie.lyx.org (195.0.254.205), 30 hops max, 38 byte packets
...
11 Norge2.NO.eu.net (193.71.71.17) 34.076 ms 33.891 ms 36.877 ms
12 storeslem.troll.no (195.139.0.102) 42.640 ms 46.310 ms 36.874 ms
13 * * *
Marko
Hi!
this patch adds FormCitation implementation for Gnome frontend. I've
extended the standard features of this dialog by (1) adding a small BibTeX
parser for presenting authors, title, journal name and year in the
bibliography list; (2) adding the possibility for search the records that
On 8 Sep 2000, Jean-Marc Lasgouttes wrote:
Let's face it: if you want to a tearable menu to change when the
cursor moves you will have to do _something_. What I would try to do
if I were to write the gnome frontend is first to build the menus at
update() time and see whether it causes
On Sat, 9 Sep 2000, John Levon wrote:
My question is what would break if this was moved into the ctor
for LyXGUI, making GUIRuntime a non-static, with LyXGUI storing a pointer
to it ?
Would the Gnome stuff break ? Marko ?
no problem. it should be very similar to kde.
marko
Juergen, Gnome implementation has a tiny bug: the strings app_id and
app_version should be static too due to a "feature" of Gnome--.
Marko
On 11 Sep 2000, Jean-Marc Lasgouttes wrote:
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
Marko The problem is whether menus and toolbars should have their own
Marko means to track the state of LyX actions or there should be some
Marko general way to inform about
On Wed, 13 Sep 2000, Allan Rae wrote:
There shouldn't need to be much if any bending. As Marko pointed we could
end up with a TOC in a menu, a toolbar and a dialog. They all still need
updating. I'd prefer that they were triggered by the same update()
signal. A TOC menu that isn't
Hi!
this patch adds TOC and *Formats menu items to the Gnome menubar
implementation. TOC menu updates itself automatically using the
ListsTracker class. The current implementation doesn't support large TOCs
and you can't manage your references via Gnome menu yet. However, the
current
a) If something's easy quick in LaTeX then it should be easy quick
in LyX (unless it really isn't very common).
b) Actions which are used frequently should be a single key-press,
even if that's not very easy to remember. You learn it.
c) Actions which are used rarely should be
Incidentally, I haven't actually configured my setup to use kde, just hacked
the Makefile in src/frontends/kde a little. I'm running kde2.0Beta4 on this
box. It was compiled my someone in Austria, I expect with g++. I run cxx
here. Am I right in saying that I won't be able to link in the
On 15 Sep 2000, Jean-Marc Lasgouttes wrote:
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
Marko On contrary, when you try to add
Marko new citation to the citation list in LyX, (1) you have to
Marko trigger somehow the citation box (I know only how to do it with
M
On 15 Sep 2000, Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars You don't need to master regeps to use them "lars" is also a
Lars regexp.
But then you have to understand why . * and many others behave
strangely.
All I meant to say is that
On 15 Sep 2000, Lars Gullik Bjønnes wrote:
| Any good library (C/C++) which is able to check whether a string matches
| given regexp. Return value TRUE/FALSE/invalid regexp is expected :)
We already have that included under src/support so it is easy to use.
The following patch adds
On 15 Sep 2000, Lars Gullik Bjønnes wrote:
One not however: do not use defines, ever!
#define CONF_COLUMN "column"
should be
static string const CONF_COLUMN("column");
I will submit a patch with all these defines removed. But can you tell me
why should we avoid the defines (I
On Sat, 16 Sep 2000, Dekel Tsur wrote:
On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote:
The following patch adds support for regexp search in FormCitation (Gnome
frontend).
Why not filter the entries in the citation list (i.e. show only the ones
containing
On Mon, 18 Sep 2000, Juergen Vigna wrote:
BTW.: I got a bit out of sync with KDE/GNOME patches as I had to wait
for Lars to have a look at one of them, could you please tell me
(John Marko) which ones haven't been aplied?
Gnome patches are
Hi!
I would like to report the following bug in the mathmode:
1. create a new document (File/New)
2. open math-mode by clicking on the toolbar or by selecting Math/Math
Mode in menu
3. type "\alpha " and enjoy LyX dumping a core.
Marko
PS: I hope it is not only in my build (Gnome
On 18 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| On Mon, 18 Sep 2000, Juergen Vigna wrote:
|
| BTW.: I got a bit out of sync with KDE/GNOME patches as I had to wait
|for Lars to have a look at one of them, could you please tell me
On Tue, 19 Sep 2000, Allan Rae wrote:
Actually, I've been trying to figure out how to fit everything into the
tabbed area without requiring a dialog that is 2048pixels wide. I'm very,
very slowly getting there. At present it looks like I'll switch to a
nested tabbed dialog scheme and
Hi!
the first part of this patch adds TOC, ViewFormats, UpdateFormats, and
ExportFormats to Gnome menu. TOC is updated by "Refresh" button, as
suggested by Jürgen earlier.
The second part of this patch resulted from the discussion on LyX user
interface. I've added a possibility to ask user
On Tue, 19 Sep 2000, Allan Rae wrote:
Can't you just make it that this menu can't be torn off?
I think its not nice. I would even suggest that it will one of the most
popular menus to tear off :(. However, even if I disable this feature then
I will have to compose menus on the fly as it is
On Tue, 19 Sep 2000, Allan Rae wrote:
Can't you just make it that this menu can't be torn off?
I think its not nice. I would even suggest that it will one of the most
Only an interim measure to stop the complaints about it not being updated
unless it's closed/reattached or whatever
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| Workarea event: ENTER
| Workarea event: KEYBOARD
| XLookupBoth
| WorkArea: Key is `' [27]
| WorkArea: Keysym is `Escape' [65307]
| Workarea Diff: 2985369638
| KeySym is Escape[65307]
| Key [158
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| On 19 Sep 2000, Lars Gullik Bjønnes wrote:
|
| Marko Vendelin [EMAIL PROTECTED] writes:
|
| | Workarea event: ENTER
| | Workarea event: KEYBOARD
| | XLookupBoth
| | WorkArea: Key is `' [27
On Tue, 19 Sep 2000, Marko Vendelin wrote:
And after this you get the core dump in the same spot?
No, lyxfunc.C: line 656
called by minibuffer.C, line 73
marko
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| On Tue, 19 Sep 2000, Marko Vendelin wrote:
|
| And after this you get the core dump in the same spot?
|
| No, lyxfunc.C: line 656
|
So can you remove the c_str() in this line too
I get an error in Menubar_pimpl.C:327 code when compiling your patch:
case MenuItem::Toc: {
toc_.push_back();
toc_[toc_.size()-1].path = path;
break;
}
Jürgen, can you put the following code instead:
case MenuItem::Toc: {
ListsHolder
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
If I guess correctly this should be written as:
case MenuItem::Toc:
{
TocItem tit;
tit.path = path;
toc_.push_back(tit);
break;
}
No. toc_ is a special
On Tue, 19 Sep 2000, Juergen Vigna wrote:
Some comments:
- the TOC menu is far to long, you have to find a better solution!
(try to load the UserGuide and look at it my goes down the screen!)
True. I have to use .depth information and construct submenus as it is
done in xforms
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| Hi!
I don't like this code:
+ // setting sizes of the widgets
+ string path;
+ string w, h;
+ path = PACKAGE "/" + LOCAL_CONFIGURE_PREFIX;
+
+
On 19 Sep 2000, Lars Gullik Bjønnes wrote:
Marko Vendelin [EMAIL PROTECTED] writes:
| On 19 Sep 2000, Lars Gullik Bjønnes wrote:
|
| Marko Vendelin [EMAIL PROTECTED] writes:
|
| | On Tue, 19 Sep 2000, Marko Vendelin wrote:
| |
| | And after this you get the core dump
On Fri, 22 Sep 2000, Angus Leeming wrote:
5. We need some method of toggling between the three LaTeX output states. As
the left mouse button opens the inset, this leaves the right mouse button.
Jürgen seems very against using this to toggle between states, so RMB will
launch a (very
On Fri, 22 Sep 2000, Garst R. Reese wrote:
I'll expand my earlier suggestion.
Let menu shortcuts be M-Uppercase letter
bindings M-lowercase letter
The menus all start with an uppercase letter anyway.
When in math mode in particular I prefer not to have to resort to the
menu and want
On Sat, 23 Sep 2000, Garst R. Reese wrote:
Did you see my proposal to use M-capital-letters for menu shortcuts,
which would leave M-m available for math key bindings.
Would you find that acceptable?
Marko observed:
And LyX will be the only program I know to do that :). Actually, I know
Hi!
this patch completes the rewrite of FormCitation in Gnome frontend to use
the action area within the main window. This implementation of the dialog
has two main modes. First, it allows to insert a new citation by asking
for a keyword (regexp) and showing list of citation matching a filter.
On Mon, 25 Sep 2000, Allan Rae wrote:
I just jumped from first to last emails in this thread so I may have
missed a little bit ;-)
On Sat, 23 Sep 2000, Marko Vendelin wrote:
On Fri, 22 Sep 2000, Angus Leeming wrote:
5. We need some method of toggling between the three LaTeX
On 27 Sep 2000, Jean-Marc Lasgouttes wrote:
[...]
Concerning for example sans-serif, the question is to know when you
need it, and what you want to express with it. It this "idea" that
should be in the toolbar, not the pysical representation.
Finally, two points:
- the character popup
And if you comment this out then it fails later in src/tabular.C
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/lib/sigc++/include -I./gnome
-I/usr/local/lib/gtkmm/include -I/usr/local/lib/gnomemm/include
-I/usr/local/include -I/usr/include -DNEED_GNOMESUPPORT_H
-I/usr/lib/gnome-libs/include
Hi!
this patch adds FormRef and FormError to fine family of the dialogs ported
to Gnome frontend. These dialogs are implemented using an "action" area
to make the work with references as fast and convenient as possible and
scanning error messages less disturbing.
Marko
On 11 Oct 2000, Jean-Marc Lasgouttes wrote:
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
Marko this patch adds FormRef and FormError to fine family of the
Marko dialogs ported to Gnome frontend. These dialogs are implemented
Marko using an "action" a
On 11 Oct 2000, Jean-Marc Lasgouttes wrote:
Get www-devel from the cvs server. This is the developpers web site
(and www-user is www.lyx.org).
Here is the update of guii.php3.
Marko
www.gnome.patch.gz
Hi!
this patch makes the Gnome frontend dialogs which use the "action" area to
hide on update signal. Thus, when user switches the document the dialog
will disappear. I've also replaced gettext N_() with _() where
appropriate. Finally, I changed the Menu code to use new Menu::expand
method.
On Fri, 13 Oct 2000, Dekel Tsur wrote:
On Mon, Oct 09, 2000 at 04:23:39PM +0200, Jean-Marc Lasgouttes wrote:
To put it another way, I thought I could just add a Menu* member in
menuitem and that Menu::expand would just populate that for items of
type Submenu for Toc and Ref. I have a
Overall the xforms stuff is looking very nice. I took at peek at the
gnome and kde stuff as a result of the change to update and
updateBufferDependent. There seems to be an aweful lot of code just to
get things running with gnome.
True! There are two reasons for it. First, I decided to
please don't apply this patch. Its in terrible conflict with the recent
changes of updateBufferXXX. I'll repost a new version as soon as the
conflict is resolved.
Marko
On 13 Oct 2000, Jean-Marc Lasgouttes wrote:
Marko True, you can add/edit the reference quite fast with the
Marko dialog.
So should it be removed? It adds quite a bit of complexity to the menu
code...
I would be happy with it: we can then declare Menubar in guii.php3 as
"Completed".
this version should work/compile just fine with new updateBufferXXX.
Marko
gnome.cleanup.2.patch.gz
On Sat, 14 Oct 2000, Allan Rae wrote:
On 13 Oct 2000, Jean-Marc Lasgouttes wrote:
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
Marko is there any particular reason for using NULL instead of 0 in
a lot of your code? Is this a gnome convention? Where is it
Date: Sat, 28 Oct 2000 10:39:04 +0100
From: Yann MORERE [EMAIL PROTECTED]
To: LyX devel [EMAIL PROTECTED]
Subject: Problem compiling lyx with gnome on a linux box
Hello lyx developpers...
I've got problems compiling lyx with gnome on linux box
here is the error whene configureing
Hi!
the attached patch replaces NULL with 0 in the gnome frontend code and
makes the frontend to compile again by replacing/adding update() with
updateSlot() where appropriate. It seems that DialogBase is changing its
methods quite often which is one more good reason to establish class
On 30 Oct 2000, Jean-Marc Lasgouttes wrote:
"Marko" == Marko Vendelin [EMAIL PROTECTED] writes:
Marko the attached patch replaces NULL with 0 in the gnome frontend
Marko code and makes the frontend to compile again by
Marko replacing/adding update() with updateSlot() where a
Hi!
this small patch allows to compile and link gnome frontend version. I've
added some new xforms object files to the appropriate list in
gnome/Makefile.am and a new signal is added in Dialogs.C as it is in the
xforms version.
Marko
patch.gnome.201100.gz
I'm not sure what we gain with that. The problems which exist in some
architectures (e.g. how do you update a dynamic menu when it is teared off)
will continue to exist anyway. If you find a good solution for a
frontend, I am sure it will work with the current scheme.
The only problem of
Try to
1. create new document
2. press Escape, core dumped
lyx -dbg any:
[...]
Workarea event: ENTER
Workarea event: KEYBOARD
XLookupBoth
WorkArea: Key is `' [27]
WorkArea: Keysym is `Escape' [65307]
Workarea Diff: 2985369638
KeySym is Escape[65307]
Key [158][]
Again, it seems that there is
Hi!
On 7 Feb 2001, Jean-Marc Lasgouttes wrote:
"John" == John Levon [EMAIL PROTECTED] writes:
John So I must update every dynamic menu/toolbar item on every
John update(). OK, I suppose that's not too bad. But what is it
John you're actually informing the frontend of ? It seems that the
On Thu, 8 Feb 2001, Allan Rae wrote:
On Wed, 7 Feb 2001, Marko Vendelin wrote:
[...]
John How would your method cope with a number of different toolbars
John for different things ? Do you call update() on each one ? Why
John not just let the frontend decide what needs updating - why
I am not sure whether any of my code is still used in LyX, so it is far
from clear whether I have any rights at all. But, if you need, please feel
free to add to the list of people which grant permission to licence their
contributions to LyX under the Gnu General Public Licence, version 2 or
I am not sure whether any of my code is still used in LyX, so it is far
from clear whether I have any rights at all. But, if you need, please feel
free to add to the list of people which "grant permission to licence their
contributions to LyX under the Gnu General Public Licence, version 2 or
current CVS does not compile with KDE frontend due to the difference in
Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs
class constructor expects LyXView* as its argument in Xforms frontend
(src/frontends/Dialogs.h src/frontends/xforms/Dialogs.C) and LyXFunc* as
an
> all development has been done with the xforms code. The code in the kde
> directory was written as proof of concept a long, long time ago. As such, it
> has lagged behind...
>
> You are correct to report that the code in kde/Dialogs.C is inconsistent with
> that in xforms/Dialogs.C. It is
I've tried to add some elementary support of GTK/Gnome frontend to LyX.
The composed code and collection of configure .m4 scripts brings the GTK
frontend to the same level as KDE one --- showing the copyright dialog
box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK
and
On Tue, 11 Jul 2000, Lars Gullik Bjønnes wrote:
> | 2. Make LyX compatible with the string class included in libstdc++ by
> | fixing files src/support/lstrings.C (lines 184 and 201,
> | string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string
> | interaction).
>
> You mean
Hi!
the attached patch together with additional files included into the
.tar.gz archive adds elementary support for GTK/Gnome frontend: configure
scripts, Gtk/Gnome initialization, Gnome event loop processing, and
Copyright dialog box implementation.
It should be easy to use this code on the
Hi,
> It seems that we miss an .m4 file which defines AM_PATH_GTK (and
> probably others). It is now impossible for me to compile for xforms,
> since the configure file produced by autoconf is plain wrong...
I've obtained a fresh copy of lyx-devel this morning (cvs checkout) and at
least
> I do have all this files, but I think you have some gtkxxx.m4 files in
> your /usr/share/aclocal (or whereever) directory, that got installed
> when installing gtk. A simple check: grep AM_PATH_GTK
> config/gnome/*.m4 reveals that this macro is used there, but never
> defined.
I see! The
> We certinly need the AC_LANG_CPLUSPLUS, since otherwise checks for the
> C++ compilers features are done with the C compiler :) I put it back
> in, and added an AC_LANG_CPLUS_PLUS later.
>
> In general, configuring with AC_LANG_CPLUS_PLUS would be better, since
> we will compile with the C++
> Could you show us this small program? It might be that it uses a
> valid C syntax that is not valid C++. These things are easy to fix in
> general.
I mean the program used inside the script (gtk.m4) for checking GTK
libraries installation.
Marko
On 25 Jul 2000, Jean-Marc Lasgouttes wrote:
> Yes, I understand. But which one is it? And what is the error message
> in config.log?
I've checked out the latest version from cvs and everything worked fine!
GTK, gnome, gtkmm, gnomemm were configured without any errors. Thus, it is
hard for me
On 25 Jul 2000, Jean-Marc Lasgouttes wrote:
> Yes, you should comment out the AC_LANG_C at line 89 of configure.in.
AC_TRY_RUN compiles gtk program with C++ compiler instead of C compiler.
That's why environment variable CFLAGS doesn't have any effect (see line
58, file
1 - 100 of 176 matches
Mail list logo
