kde frontend: LyXFunc or LyXView
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 argument in KDE frontend (src/frontends/kde/Dialogs.C). Error message: # ./configure --with-frontend=kde ... # make ... g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I/usr/lib/qt-1.44/include -I/usr/include/kde -I/usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/Dialogs.pp -c Dialogs.C -o Dialogs.o Dialogs.C:13: prototype for `Dialogs::Dialogs(class LyXFunc *)' does not match any in class `Dialogs' ../../../src/frontends/Dialogs.h:119: candidates are: Dialogs::Dialogs(class Dialogs ) ../../../src/frontends/Dialogs.h:117: Dialogs::Dialogs() ../../../src/frontends/Dialogs.h:55: Dialogs::Dialogs(class LyXView *) Regards, Marko
Re: kde frontend: LyXFunc or LyXView
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 should be
Dialogs::Dialogs(LyXView * lv)
{
dialogs_.push_back(new FormCopyright(lv, this));
dialogs_.push_back(new FormPrint(lv, this));
dialogs_.push_back(new FormPreferences(lv, this));
// reduce the number of connections needed in
// dialogs by a simple connection here.
hideAll.connect(hideBufferDependent.slot());
}
Note, however, that this code won't compile either as no Print and
Preferences dialogs for kde. Commenting them out will allow the code to compile
(and maybe even link??) but the resulting executable will not have these
dialogs. Seems a bit pointless, no?
If, of course, you wish to write the missing dialogs...
Angus
The attached small patch allows to compile kde frontend. The resulting
executable misses FormPrint and FormPreferences dialogs but shows
FormCopyright using kde libs.
Marko
patch.gz
GTK/Gnome frontend and string class
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 Gnome libraries). GTK-- and GNOME-- rely on STL string class which is not good enough for LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). This is a problem since in LyX string class is typedefed to lyxstring and the resulting code does not link properly with GTK-- and GNOME-- libraries. The following solutions to this conflict between GNOME/Gtk and LyX popped into my mind: 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers 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). 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this libraries with lyxstring. 4. Find better implementation of STL for Linux and use its string class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ is not good enough to compile LyX). Which of these (or any alternative) solutions should be used for LyX GTK/Gnome frontend? Regards, Marko
Re: GTK/Gnome frontend and string class
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 hope. The lyxstring tries to be close to API compatible with std::string. Well, it should be possible to find API and libstdc++ compatible implementation. For example, instead of comparing string and char* directly (src/support/lstrings.C, lines 184 and 201), one can make temporary string object from char* and compare it with other string. It is not as effective implementation as the current one, but it will work just fine with libstdc++. It is hard for me to say how to re-implement the code in src/lyx_cb.C (line 1109) to make it compatible with libstdc++ since STL is very new to me. | 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this |libraries with lyxstring. Isn't Gtk-- and Gnome--- a bit large for that? Yes, it is. However, we can include scripts that build Gtk--/Gnome-- automatically with lyxstring instead of std::string. At least, the resulting frontend code should work fine and we can drop it later (after release of libstdc++-v3). Can we have an interim solution where we use char* to communicate between lyx-core and the gtk frontend? When Gcc 2.96 is released it will hopefully be with the new libstdc++-v3 library, and then there will be no problems. This will require isolation of Gtk/Gnome frontend code from the rest of the LyX code. For example, it will be not possible to include even src/frontend/Dialogs.h directly from the frontend implementation since it contains "#include "LString.h"". I think such solution will lead to unnecessary code in LyX. Marko
GTK/Gnome frontend elementary support
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 platform with good STL string implementation. In such case you need standard gtk, gnome, libsigc++ , gtk-- and gnome-- libraries. On my platform (redhat linux 6.1, egcs 1.1.2) LyX uses LyX string class instead of STL string. To use gtk-- and gnome-- with LyX I recompiled these libraries after replacing "#include string" by "#include "LString.h"" in the source files of the libraries. To make our life easier I've written two small scripts that patch gtk-- and gnome-- libraries and compile them. Please note that running these scripts is DANGEROUS since it may change your source files. The following are instructions for getting Gtk/Gnome frontend running in the platforms that lack good STL string implementation (it worked on my platform): * install Gtk, Gnome, and libsigc++ * download gtkmm-1.2.1.tar.gz and gnomemm-1.1.10.tar.gz from http://gtkmm.sourceforge.net/download.html (click "sourceforge download area" on this page) * create a new directory and copy gtkmm-1.2.1.tar.gz, gnomemm-1.1.10.tar.gz, lyxgtk.sh, and str2lyxstr.sh to this directory (lyxgtk.sh and str2lyxstr.sh are attached to this e-mail) * cd to this directory * read and edit script lyxgtk.sh (set source and install directories) * run script lyxgtk.sh * include directory with installed new gtk and gnome libs to PATH and LD_LIBRARY_PATH as first directories (subdirs bin and lib, respectively). * cd to lyx source directory * run autogen.sh * run configure with the following options: --with-frontend=gtk --without-included-libsigc --disable-sigctest --with-gnomemm-config-path=NEW_GNOMEMM_LIB/lib/gnomemmConf.sh --disable-gtkmmtest * run make Please note, that compiled Gtk--/Gnome-- libraries are usable only with LyX. Finally, to make configure script working I had to disable AC_LANG_CPLUSPLUS in configure.in (line 66). Otherwise gnome configuration scripts were not working properly. It will be very nice if someone with good knowledge of configure.in magic would take a look on this problem. Regards, Marko #!/bin/bash # This script is DANGEROUS! It replaces # "#include string" with "#include "LString.h"" in the files in # current directory (recursively!). This can change YOUR source files. # Use it at your own risk. FILELISTCC=`rgrep -r -l "#include string" . | grep "\.cc"` FILELISTH=`rgrep -r -l "#include string" . | grep "\.h"` FILELISTGEN=`rgrep -r -l "#include string" . | grep "\.gen_"` for i in $FILELISTCC $FILELISTH $FILELISTGEN; do cat $i | sed -e 's/#include string/#include "LString.h"/g' .tmpfile mv .tmpfile $i done #!/bin/bash # This script is DANGEROUS! It uses script srt2lyxstr.sh to replace # "#include string" with "#include "LString.h"". This can change YOUR source files. # Use it at your own risk. # extracting GNOME-- and GTK-- tar zxvf gnomemm-1.1.10.tar.gz tar zxvf gtkmm-1.2.1.tar.gz # Please specify the directories with GTK--, GNOME--, LyX source, and the directory # to which new GTK--/GNOME-- libraries should be installed. GTKMMDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/gtkmm-1.2.1 GNOMEMMDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/gnomemm-1.1.10 LIBINSTALLDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/root LYXDIR=/home/users/markov/cpp-files/lyx/lyx-devel # Please note that script creates temporary directory $GTKMMDIR/../.tmpdir . # Change the script if this is not acceptable for you. mkdir $LIBINSTALLDIR export MAKE="make" export CXXFLAGS="-DUSE_INCLUDED_STRING -I$LYXDIR/src" CURRDIR=`pwd` STR2LYXSTR=$CURRDIR/str2lyxstr.sh # gtkmm cd $GTKMMDIR ./configure --prefix=$LIBINSTALLDIR echo -e "all: \ninstall: \n" gdk--/tests/Makefile mv src/gtkmmproc ../.tmpdir $STR2LYXSTR mv ../.tmpdir src/gtkmmproc make make install cd $CURRDIR # gnomemm export PATH=$LIBINSTALLDIR/bin:$PATH cd $GNOMEMMDIR ./configure --prefix=$LIBINSTALLDIR --disable-gtkmmtest $STR2LYXSTR make make install cp src/gnomemmConf.sh $LIBINSTALLDIR/lib cd $CURRDIR gnome-add.tar.gz gnome-patch.gz
Re: GTK/Gnome frontend elementary support
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 frontend works fine here. Current cvs should contain new directories config/gnome src/frontend/gtk Please check, whether you have these directories in your local copy and whether autogen.sh script contains a huge line with "for fil in config/lyxinclude.m4 config/libtool.m4 config/gettext.m4 config/lcmessage.m4 config/progtest.m4 config/sigc++.m4 config/kde.m4 confi g/gnome/aclocal-include.m4 config/gnome/gnome-print-check.m4 ..." Marko
Re: GTK/Gnome frontend elementary support
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 tar.gz and small patch to autogen.sh adds 1 .m4 script (config/gnome/gtk.m4). I've tried to generate configure script with minimal amount of files in /usr/share/aclocal and it worked now in my system. Sorry for the mess. Marko patch.gtk.m4.add.gz config.gnome.tar.gz
Re: GTK/Gnome frontend elementary support
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++ compiler. If the gnome scripts are broken with C++, they should be fixed. What are the errors? I cannot test, since I do not have gnome installed here. Well, it seems that script gtk.m4 fails to compile a small gtk program with AC_LANG_CPLUSPLUS. When I inserted AC_LANG_C before AC_TRY_RUN (gnome/gtk.m4, line 65) and AC_LANG_CPLUSPLUS at the end of this script, the program was compiled. However, the configure script produced slightly different Makefile (one CPPFLAGS option was missing). Thus, to resolve this problem one needs to run AC_TRY_RUN with AC_LANG_C and somehow keep the configuration of AC_LANG_CPLUSPLUS. I don't know how to do it. PS: Marko, are you on the lyx-devel list? yes, almost for an hour already :). Marko
Re: GTK/Gnome frontend elementary support
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
Re: GTK/Gnome frontend elementary support
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 reproduce the problem. Marko
Re: GTK/Gnome frontend elementary support
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 config/gnome/gtk.m4). If we add line CXXFLAGS="$CXXFLAGS $GTK_CFLAGS" after line 58 then this test is passed. Marko
Re: GTK/Gnome frontend elementary support
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-- only as it is now, but I am not sure whether gnome-- covers libgnome functionality completely. Since all the scripts seems to be working now we may either leave as it is or remove unnecessary scripts. However, if we will need anything directly from gnome libraries we should add these scripts later. Both solutions should work. To check it, I've removed GNOME_INIT, GNOME_COMPILE_WARNINGS, GNOME_X_CHECKS from configure.in file, leaved only config/gnome/gtk--.m4 and config/gnome/gnome--.m4 in autogen.sh script and everything configured/compiled just fine. Marko
Re: GTK/Gnome frontend elementary support
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). Could you send a patch? The patch is attached. Before committing it I propose to move files gnome--.m4 and gtk--.m4 from config/gnome to config and remove directory config/gnome. BTW.: We were discussing about your naming of the src/frontends/gtk directory. Are you planing to do GNOME port or a GTK port? It seems to me that GNOME port will be easier to accomplish since GNOME libraries have several useful additions comparing with plain GTK. For example, to implement About dialog with GTK I had to write small class with actual implementation. The GNOME has this kind of dialog box already and it is consistent with the similar boxes of other GNOME applications (Gnumeric et al.). I think that this consistency with other GNOME applications is very important and it should make learning and using LyX much easier for new users. I am going on vacation this Friday and, unfortunately, I didn't have any chance to work on LyX recently. To keep the porting to Gnome rolling it might be wise to ask for help from Gnome programmers. However, before announcement in Gnome news site we should be absolutely sure that gnome/gtk frontend builds cleanly and LyX menu/toolbar system is ready for porting. I think that there will be a great interest to this port but it may vanish quickly if LyX is not ready yet. To build LyX as it is now with gtk/gnome frontend enabled one has to 1. add symbolic links that point to ../xforms/Menubar_pimpl.C, ../xforms/Menubar_pimpl.h, ../xforms/Toolbar_pimpl.C, ../xforms/Toolbar_pimpl.h from src/frontend/gtk 2. add these files to Makefile.am file listing (libgtk_la_SOURCES) 3. run configure with the following options: --with-frontend=gtk --without-included-libsigc --disable-sigctest --without-included-string 4. make Marko patch.gnome.cleanup.gz
Re: GTK/Gnome frontend elementary 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 xterm so I cannot copy it to this mail), but after rerunning configure with --without-included-string compilation went good, ... On my system (redhat-6.1, gcc 2.95.2) I don't have this problem. "--with-frontend=gtk --without-included-libsigc --disable-sigctest " works fine here. Marko
Re: GTK/Gnome frontend elementary support
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 Juergen directory)! It would be a good idea to grab what Alejandro did last year. He made these abstract tool/menubar from the old devel branch for gnome. I would like to look on the code, but for some unknown reason I can't reach Mexican mirror of LyX site : http://www.mx.lyx.org/glyx/ . Maybe I need a visa? Anyway, can someone send me the code developed for gLyX? Marko
Gnome frontend: Menubar implementation, patch included
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 with gnome frontend support, LyX has two windows: LyXView (without menubar) and new GLyxAppWin (with menubar). The following two problems occured: Manubar::update : Since Gnome menu may be easily used as toolbar by "tearing off" the menu, I had to update constantly state of the widgets as it is done for Toolbar. This means that after each keypress by user LyX has to check state of all the actions presented in the menu. Is there any way to register a callback function which is called when the corresponding action state has changed? Will it be more effective than walking through vector with actions and asking the state of each action? Shortcuts: Gnome applications have common shortcuts, such as F3 for Open File, for example. Which shortcuts should be default for LyX --- as it is now or common Gnome ones? Marko gnome-menus.gz gnome-menu-new-files.tar.gz
RE: Gnome frontend: Menubar implementation, patch included
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
RE: Gnome frontend: Menubar implementation, patch included (fwd)
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 needs just to add a loop for (int i=0; i5; ++i) Gnome::Main::instance()-iteration(FALSE); instead of running Gnome::Main::instance()-iteration(FALSE) only once per loop in LyXGUI::runTime(). So, I think that this problem will disappear as soon as all LyX events are handled by Gnome. Marko
Re: Some words to frontends!
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 should for now concentrate on the dialogs (as they can be fully implemented and it's really enough work for now) I think you are right. However, can you be a little bit more specific about "some bases which do not work". May be I can fix it before moving on with other parts? Marko
Re: Some words to frontends!
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 implementation is so different from Menu? It seems to me that menus and toolbars are quite similar: (a) they both provide link between user's mouse (keyboard) and LyX command, (b) they both have to be updated regularly. The main difference between tool- and menubar which I see is the fact that Menus are hierarchical. However, we can decode the menu levels for use in the toolbars as follows: main-toolbars collection of the toolbars in "normal mode" |-- general-toolbar --- present toolbar | |-- layout --- selection box in the toolbar (Standard et al) | |-- fontsize --- new selection box (for example) |-- math-toolbar |... Thus, it is possible to use very similar interfaces for menu- and toolbars. Wouldn't that make writing-/configuring LyX easier? Or I don't see some important difference between toolbar and all these menus? :) Marko PS: I'll start to work on the dialogs meanwhile...
Gnome frontend: print inserturl dialogs
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 cover Gnome very well and produces the code for older version of Gtk--. So, I decided to use clear and fully functional C interface instead of incomplete C++ one. The patch includes changes in configure script to check for Gnome installation (the check is before AC_LANG_CPLUSPLUS); some small cleanup in config/lyxinclude.m4 (frontend help message); and enhancement of the performance of Gnome menus. To compile this patch you need to copy all unimplemented dialogs in Gnome frontend from Xforms frontend (or set up corresponding symbolic links). Marko gnome-print-url.newfiles.tar.gz gnome-print-url.gz
Re: Gnome frontend: Menubar implementation, patch include
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 Gnome. By using Gnome libraries it is easier for me to write the code since there are several useful classes (widgets) which you will find in Gnome libraries only. In addition, using the Gnome libraries allows me to add some nice small features to dialogs which are not there in Xforms frontend. For example, history in the dialog entry box (it remembers your last 10 inputs). You're allowed to support this and send a patch for a clean gtk frontend ;) I guess we core developers don't work on the frontend side (only the xforms one as we have to build a base for the porters) all others are made by people who would like to see their prefered toolkit supported. So if you want a clean GTK frontend "do it yourself" or find some one (maybe on the gtk-lists) to do it for you #:O) I think it will be better to join the forces and complete one frontend first. It should be relatively easy then to port Gnome frontend to Gtk (or vice versa). Marko
Re: Gnome frontend: print inserturl dialogs
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 the code for older version of Gtk--. So, I decided to use clear and fully functional C interface instead of incomplete C++ one. So are you using anything from gtk-- and gnome-- now or will it all be done using gnome and gtk directly? No, I use the mix. The menus are implemented in gnome--/gtk-- with small exception: update function uses gtk calls directly. I can use gtk-- there too, but there is no reason to do so. For dialogs the situation is a little bit more complicated. I generate C source code to create dialog and process some elementary callbacks (such as disabling entries according to the state of radiobuttons or adjusting minimal value of "To" field when "From" field is changed /* To=From */). Then, in dialog ::show method I use gtk-- wrapper to get pointers for all dialog elements that are required by update/apply methods (there is no need to check value of the label, for example). These pointers are used for communication between FormXXX and dialog using signal/slot mechanism common in gtk--/gnome--. Actually, the implementation is easier than it sounds --- take a look into FormUrl.C ::show, update, and apply methods (or FormPrint for lengthier example). To compile this patch you need to copy all unimplemented dialogs in Gnome frontend from Xforms frontend (or set up corresponding symbolic links). Maybe you should try some automake magic to create the symlinks at compile time. Try filling in the BUILT_SOURCES variable and then provide targets that create the symlinks if needed. Well, I'll better try to catch up :) Marko
Gnome: FormToc FormIndex
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 compile LyX). Marko gnome.toc.index.patch.gz gnome.toc.index.newfiles.tar.gz
RE: Gnome: FormToc FormIndex
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 rest are empty, that's
true. In general, more complex dialogs will require some callbacks. I
think that if we will remove these (empty) files then we will have to
postprocess Glade-generated _interface files which include _callbacks.
- would it be possible to postprocess the .[ch] files so that we can get
.[Ch] files as we do with fdesign generated files? (I would help to
implement this if you like it!)
In all computers that I've seen, gcc compiles files faster than g++. Do we
need to have compilation times longer? :)
- I don't see project files do you mean the .glade files? I did add the
directory and files the last time too!
yes, these are "project" files for each dialog.
- what is this support.[ch] is it always generated by glade?
yes. at least one function is used by me directly: lookup_widget.
- 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 inside a switch like:
kb_action action;
string argument;
if (lyxaction.isPseudoAction
action = lyxaction.retrieveActionArg(ac, argument);
else
action = static_castkb_action(ac);
switch(action) {
case LFUN_FILE_OPEN:
gitem = Open(cback);
break;
case LFUN_QUIT:
gitem = Exit(cback);
break;
...
}
This is much better implementation. Should I change it or you will make
it?
- I will also have a look why some menu-items are never enabled and/or
displayed wrong.
Is it Gnome-specific or the same trouble is with XForms implementation?
Marko
RE: Gnome: FormToc FormIndex
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 to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). In all computers that I've seen, gcc compiles files faster than g++. Do we need to have compilation times longer? :) Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) I'm eager to hear it. Or is it FAQ-type question and I should look into developers-FAQ? - what is this support.[ch] is it always generated by glade? yes. at least one function is used by me directly: lookup_widget. Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? Generally, glade produces this file for every project. However, as far as I have seen it is almost identical each time. You can desire not to produce this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. This is much better implementation. Should I change it or you will make it? Well it's your baby :) I'll patch it. This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) 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. Marko
RE: Gnome: FormToc FormIndex
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. Undo/Redo problem disappeared when I called update() after executing LyX action in "void Menubar::Pimpl::callback(int action)". However, I don't think that this is the right place to do so. Marko
RE: Gnome: FormToc FormIndex
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 logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) I suppose that we need to call update after each action is executed regardless of the source of the action (menu, toolbar, pipe). Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? 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 (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? Marko
RE: Gnome: FormToc FormIndex
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 (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the responsibility of the programmer that implements some new action to define its state this way (we can use LyXFunc::ToggleOff as the default for this kind of actions). Marko
some qustions: FormCitation, FormTabular
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 entries, each key is very lengthy containing author names, journal name, pages, year, ... So, when the current implementation of FormCitation is fired up, I see huge amount of keys (unsorted!) with almost no hope to find the right one :(. Thus, it will be nice to have at least a possibility to search the references. To make looking up of the references a little bit more fun, I would like to have a columned list with author names, title, year in the separated columns. This means that I have to parse the contents of the blist[i].second field. How should I implement it? Do we have bibtex parser within LyX? What should I expect to find in this field? FormTabular: It looks like the functionality of this dialog box is duplicated (partly) by Edit/Table menu. What is an expected evaluation of this dialog? Will it be just used for borders or we will have two way to add/remove columns ... ? Or maybe we will have a special toolbar for tables? Finally, how can I fire up FormGraphics? Menu? Marko
Gnome: Menu patch
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 inside a switch like:
kb_action action;
string argument;
if (lyxaction.isPseudoAction
action = lyxaction.retrieveActionArg(ac, argument);
else
action = static_castkb_action(ac);
switch(action) {
case LFUN_FILE_OPEN:
gitem = Open(cback);
break;
case LFUN_QUIT:
gitem = Exit(cback);
break;
...
}
here comes the patch that implements it.
Marko
gnome.menupatch.gz
anoncvs.lyx.org www.lyx.org down?
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
Gnome: FormCitation
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 contain user-specified word(s). The dialog remembers its size, sizes of the paned views, and sizes of the columns in the list. I had to implement the BibTeX parser since I am not familiar with YACC which is used by other BibTeX-parsing programs. At least, it parsed all my BibTeX files. There is one performance issue which I would like to outline. It seems to me that LyX loads BibTeX files every time when FormCitation is called. It might be OK if the files are small, but for databases with more than 1000 records the loading takes several seconds. Can't we cache the BibTeX files as it is done by Emacs with reftex package, for example? Finally, is there anybody working on natbib support? Marko gnome.formcitation.patch.gz gnome.formcitation.newfiles.tar.gz
Re: InsetRef suggestion: comments please
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 performance problems. If it is the case (and it might be), I would create the menus in set(), cache the status of each lyxfunc used and, at update() time, change the state of the entries of the existing menu (like for the toolbar) on a case by case basis. For OptItems, one would have to insert/delete entries in the existing menu (which should be possible). And with a bit of double buffering, this should work well enough. The problem is whether menus and toolbars should have their own means to track the state of LyX actions or there should be some general way to inform about the change of the status to all interested parties. At present, we have to check the status of each lyxfunc used in the menus and toolbars during update. I think that this leads to duplicated code and to unnecessary CPU load. The other solution is to implement some kind of state machine which will completely describe the current state of LyX (which documents are open, cursor positions, TOC, LOF, LOT, LOA, bold on/off, emphasize on/off, ...). Every time when some state is changed this machine will notify all GUI elements (menu, toolbar, status bar, programs connected through lyxserver) by distributing a signal to all interested parties with exact description of the change (for example, title of section 3.1 is changed). I think this solution should lead to faster and cleaner code, but maybe I am wrong... The second advantage is that we can store the state of this machine during GNOME (KDE) logout and load it during login. Maybe something like this is implemented in LyX already and I just don't know anything about it or it has been discussed and rejected already. If true then sorry for spam. Marko
Re: GUIRuntime init ?
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
Re: GUIRuntime init ?
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
Re: InsetRef suggestion: comments please
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 the change of the status to all Marko interested parties. At present, we have to check the status of Marko each lyxfunc used in the menus and toolbars during update. I Marko think that this leads to duplicated code and to unnecessary CPU Marko load. Do you have evidence that the calls to LyXFunc::getStatus() have a high cost? I think that having checks all over LyX code (Oh, we just changed the font! let's tell the menu about that) would have a high readability cost on the kernel code. Of course, if a profiler shows that getStatus is very expensive... You are right, LyXFunc::getStatus() is not expencive. I've tried to move cursor through the document and took almost the same amount of time to reach the end of the document regardless to whether I updated the menus or not. However, it is interesting to note that CVS version of LyX is consederably slower than LyX 1.1.5 (compiler options are different?). Also, what kind of duplicated code are you thinking about? Since toolbars and menus are almost the same, I have to implement status tracking for both of them. For example, toolbar may contain TOC too. My first idea when designing this code was to have an abstract interface for the different frontends (with add() calls and things like that), but Asger somehow convinced me that with some GUI toolkits it is not possible to add an entries to a menu one by one (now I believe he was just drunk, but the code is written). :). Marko Every time when some state is Marko changed this machine will notify all GUI elements (menu, Marko toolbar, status bar, programs connected through lyxserver) Anyway, you will have to scan the menu to see what element is interested in bold setting, won't you? No. I can connect using .connect( bindint(slot(this,Menu...::update),item_index)) In this case, no scan is needed. Marko distributing a signal to all interested parties with exact Marko description of the change (for example, title of section 3.1 is Marko changed). I guess you are interested in this one for the TOC menu. I admit that having the TOC menu in a tearable menu (and unfortunately many people will want to do that) will be a big problems (exactly for the same reason why the TOC popup does not refresh automatically). What I'd do for now is have an "update" entry on top of TOC menu entries, like for the TOC popup. It is a bit ugly, but it should work... I think we can come up with a better solution. I'll try to build up the service which will notify interested elements on the change of the state of Lists (TOC, LOA, List of the documents, etc.). The update() method of this service should be called only during an "idle" state of LyX when LyX is entering this state (where can I insert such kind of idle processing in LyX?). Such service will help us to remove Refresh button in TOC popup too. Marko
[patch] tracking lists changes, (was InsetRef suggestion ...)
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 visible, and a dialog that is closed won't be connected to that update signal so we won't be wasting time updating something that the user can't see. Well. If we don't want to mess with each gui toolkit internals and change the menus only if they are visible then we have to update the status of each menuitem regardless to its visibility. Its the way it is done in gnome frontend and the good news is that it is quite fast (at least I haven't seen any slowdown of LyX due to this constant update). I would expect the same in KDE frontend code. However, we don't have any lists in the menus yet in gnome. The toolbar TOC is likely to be just a copy of the menu TOC (Marko?) so it would only need to be updated when the user opened it (it's not a tearoff as well is it?). A torn-off menu and a dialog would both be connected to the signal and need the same update info. Probably shouldn't pass "section3.1: The new title" that is likely to difficult to do anyway (maybe get away with passing a Paragraph const), just say "update yourself" instead. So we can at least share the same update signal between the different items. Where do you activate that signal from? We should hopefully only need one or two places in the kernel for any given signal. The cursor movements should only need one place for example. The paragraph update signal could probably be in the same place but with a test to see that we have crossed a paragraph boundary. Triggering an updateTOC signal should be possible from some common area of code -- everything that causes a change to the contents of a paragraph will ask for a redraw of the paragraph won't it? Then put the update signal there with a test to make sure the paragraph would appear in the TOC to avoid unnecessary calls. The patch included with this mail adds a new class to src/frontends. This class (ListsTracker, any better name???) keeps the copies of TOC, LOF, LOT, and LOA. If any of this lists changes, the corresponding update signal is emitted. The update signal says just "Update using XXX list" without any specific detail of the change. I've used this class to update FormToc in Gnome frontend and it seems to me that we can remove "Refresh" button in this dialog :). The only problem which I see in current implementation is the place in LyX kernel which should call the ListsTracker update method. I think that this method should be called only if LyX has nothing better to do and only once during this "idle" state. I am not aware know such a nice place in lyx code = it will be nice if someone with better knowledge of lyx internals will find such a place. At present, it is called in LyXView updateToolbar and showState methods (makes lyx reallly slow). Actually, I think we can extend the same technique to track the changes in all LyX actions. However, taking into account that current implementation works quite fast it might be not feesable now. I'm not sure I like the way this thread is heading -- we could end up with a big ugly mess if we don't try to share more stuff between similar things like menus, toolbars and dialogs. to better code? Marko tracker.patch.gz tracker.newfiles.tar.gz
Gnome Menubar update
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 implementation is easily extendable to show LOT, LOF, and LOA as soon as LyX Menu will support these lists. Marko gnomemenu.patch.gz
Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various (math-mode) HMIimprovements
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 mnemonic -- easy to remember -- even if they are multiple keypresses. Things you do rarely you care less about the time it takes to perform. I would like to bring up one more example where emacs clearly outshines LyX. Namely, if you try to insert citation in emacs (reftex mode) you are asked for regular expression, presented with the list of matching items and your new citation is in the text. If you want to remove citation ... just use Backspace key. If you want to add new citation to the list of citations ... regular expression, list, select. Finally, and I think it is very important, all these operations do not require any dialog boxen and you may even sell your mouse if the emacs is the only program you use :). On contrary, when you try to add new citation to the citation list in LyX, (1) you have to trigger somehow the citation box (I know only how to do it with mouse), (2) find a new dialog box in your screen and move there with your mouse, (3) dig into the huge list of the items (you're lucky if you use Gnome frontend since you can search for items :) ), (4) press a button in the dialog to add citation. If you want to remove the citation from the list, then again you have to go through the dialog box. The same (almost) holds for insertion of references, url, index ... Wouldn't that be nice, if I press M-i i and LyX main window will split to two areas with focus on the action area, I would enter search string, select the item from small list and enjoy writing a Discussion section with fresh citation inserted! ^K^K Hopefully we can develop LyX with problem-oriented approach in mind, not as a big mess of dialog boxen and C-S-z X for simple tasks. Marko PS: Isn't $ for math mode and % for comment a part of the great LaTeX culture?
Re: patch
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 libraries because the two compilers are incompatible? Anybody got any opinions on/experiences of this? Compaq cxx on Alpha? Then you cannot link with g++ libs. It is written somewhere on Compaq cxx alpha-linux pages (release notes?). Marko
Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various (math-mode) HMI improvements
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 Marko mouse), The corresponding shortcut is then shown in the minibuffer. Well. If I want to add new citation to already existing citation list, it shows only "Opened inset" to me :(. Marko (2) find a new dialog box in your screen and move there Marko with your mouse, As far as I know, all popups appear under the mouse cursor. Is it a feature of XForms or LyX-XForms? Or I am missing something in Gnome-frontend? Marko
Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various (math-mode) HMI improvements
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 regexp support is not a top priority for many users, IMO. However, it may happen soon since it is a priority for many of the coders :) Any good library (C/C++) which is able to check whether a string matches given regexp. Return value TRUE/FALSE/invalid regexp is expected :) Marko
[patch included] Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various(math-mode) HMI improvements
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 support for regexp search in FormCitation (Gnome frontend). Marko PS: BTW, what about my patches submitted earlier (tracking TOC changes and adding TOC to Gnome Menubar) ? formcitation2.patch.gz
Re: [patch included] Re: [Jules Bean jmlb2@hermes.cam.ac.uk]Various (math-mode) HMI improvements
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 presume only with strings) ?
Marko
Re: [patch included]
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 the regexp) instead of search? Actually, it is a filter. Marko
Re: patch
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 http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg14188.html http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg14247.html They both depend on TOC lists tracking implemented in the first patch. These patches were results of the discussion on the GUI update policy of LyX. Note, that in the present form the first patch may slow down LyX considerably as indicated in the e-mail. All other patches (Gnome frontend) were applied. Marko
math-mode feature or bug?
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 frontend)
Re: patch
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 |(John Marko) which ones haven't been aplied? | | Gnome patches are | | http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg14188.html The idea is good, but the current way to update the lists is not good at all. I tink we will let this be suboptimal for the time beeing and leave everything as it is. What do you mean by "suboptimal"? Is it the basic idea of updating the list(s) by using buffer()-getTocList() (that means parsing LyX document for headings etc.) or that it is done after every action and not during "idle" time? Later we (or atleast I want to) have separate insets for headings, then it will be easy to emit the signals directly from the buffer when headings etc. change. That would be nice. It should be the same for figures, tables, algorithms and references too. Marko
Re: Dialogs only resizeable in one direction?
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 hopefully have plenty of room for each set of tabs. Maybe you should implement this dialog in Gnome frontend? It allows you to have scrollable tabs. So, 2048pixels should not be a problem :). Marko
[gnome] UI improvements menu patch
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 for information using a special area in the main window. For example, if you want to insert a new URL or Index then after selecting the command from menu or by keyboard shortcut the main window will split into two parts (LyX buffer and action area) with dialog appearing in action area. This area is closed if you (a) type URL, tab, name and hit Enter or OK button; (b) press Escape or "Cancel" button; (c) some other "action" (insert Index) will be selected. I would like to use this approach for dialogs that may appear quite often during a typing process (FormIndex, FormUrl, FormRef, FormCitation and others). It seems to me that this approach leads to faster typing since it allows you to do all your work by keyboard only and it doesn't cover your main text with the dialog. I've rewritten completely FormUrl and FormIndex. FormCitation works only in one mode: insert new citation. This dialog asks for keyword(s) or regular expression and then displays all the citations witch match your search string. It would be nice to get some feedback from people interested in Gnome frontend... Finally, is there any way to select Inset by keyboard only. I can move into math-mode or tabular or figure float by just moving around with arrow keys. However, if I move around Inset then all I can achieve is to have a cursor before or after inset. Wouldn't that be nice to have "selected" mode for insets where I can hit Enter to edit it? Marko gnome.actionarea.patch.gz
Re: [gnome] UI improvements menu patch
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 done in XForms frontend and its not very easy to do it in Gnome. Anyway, new update mechanism is expected for the lists later which will allow to refresh the menus without a dedicated button. [...] FormCitation and others). It seems to me that this approach leads to faster typing since it allows you to do all your work by keyboard only and it doesn't cover your main text with the dialog. Cool idea. I guess I should add some gnome libraries etc. and try this out or is there a framework that can be used by all ports? It is not implemented in other ports. Basically it uses the Dialog framework (create/update/hide). Also you should be aware that the long term plan was/is to allow multiple BufferViews per LyXView. Will your scheme still work in such a case? How hard to make it work? (Sorry I haven't time to look at your work till next week at the earliest so I'll just ask questions blindly instead) I don't think that this is a problem. Since the action area is used by small dialogs and it is expected to have immediate input from the user, we can either remove (hide) the dialog on switch of the buffer or make these dialogs modal. Finally, is there any way to select Inset by keyboard only. I can move into math-mode or tabular or figure float by just moving around with arrow keys. However, if I move around Inset then all I can achieve is to have a cursor before or after inset. Wouldn't that be nice to have "selected" mode for insets where I can hit Enter to edit it? C-o always used to open insets. Perhaps the bindings are broken for this also. C-o opens a new document now :( /* LyX 1.1.5 too */. Where I am supposed to position a cursor (before inset or after inset) to issue C-o ? Marko
Re: [gnome] UI improvements menu patch
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 you do to a torn off menu. User can press "Refresh" button on the menu (right before every TOC). C-o opens a new document now :( /* LyX 1.1.5 too */. Where I am supposed to position a cursor (before inset or after inset) to issue C-o ? Maybe you use CUA bindings while I use xemacs bindings 'cos it works for me. (cursor in front of the inset) I couldn't find an entry in the menu bar in my quick search. Cool, it works! Thank you. Marko
Re: even faster way to produce core dump
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][] | | Again, it seems that there is some problem with string: debugger shows | line 301 in src/lyxfunc.C Can you remove the c_str() in that line and try again? The same result. I can dump code by writing "cancel" in minibuffer after I created a new file too. Is it only my build wich has this problem or not? I am using g++ 2.95.2 strings. Marko
Re: even faster way to produce core dump
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] | | WorkArea: Keysym is `Escape' [65307] | | Workarea Diff: 2985369638 | | KeySym is Escape[65307] | | Key [158][] | | | | Again, it seems that there is some problem with string: debugger shows | | line 301 in src/lyxfunc.C | | Can you remove the c_str() in that line and try again? | | The same result. I can dump code by writing "cancel" in minibuffer after I | created a new file too. Is it only my build wich has this problem or not? | I am using g++ 2.95.2 strings. And after this you get the core dump in the same spot? No, lyxfunc.C: line 656 Marko
Re: even faster way to produce core dump
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
Re: even faster way to produce core dump
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? it doesn't help either. still dumps core. does it dump on your machine too? marko
RE: [gnome] UI improvements menu patch
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 t;
t.path = path;
toc_.push_back(t);
break;
}
or should I submit it with later patches?
Marko
Re: [gnome] UI improvements menu patch
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 vector of ListsHolder { string, Gnome::UI::Array }
used in Gnome menu code.
On another note, we dont use toc_[toc_size() -1 ] we use toc_.back()
I guess, STL is still a magic for me :). Thank's for the hint.
Marko
RE: [gnome] UI improvements menu patch
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 frontend. - I like the open of the dialogs in the other window by splitting it :) Actually, you use it every time when you code in Emacs to open files, search and do all these nice things emacs can do (I hope I haven't insulted you if you use vi to do your fine work). - you should catch the close-window of the other frame as it should not happen that you can close that one and not LyX. Well, as soon as LyXView will be ported the current other window will merge with LyXView anyway. Marko
Re: [gnome] UI improvements menu patch
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;
+
+ w = path + "/" + CONF_PANE_INFO + CONF_PANE_INFO_DEFAULT;
it should be writen as:
// setting sizes of the widgets
string path = PACKAGE "/" + LOCAL_CONFIGURE_PREFIX;
string w = pat + "/" + CONF_PANE_INFO + CONF_PANE_INFO_DEFAULT;
Where is h used?
fixed. h was used in former FormCitation implementation.
+ int i, sz;
+ for (i = 0, sz = clist_bib_-columns().size(); i sz; ++i)
+ {
+ w = path + "/" + CONF_COLUMN + "_" + tostr(i) + CONF_COLUMN_DEFAULT;
+ clist_bib_-column(i).set_width( gnome_config_get_int(w.c_str()) );
+ }
+
int const sz = clist_bib_-columns().size();
for (int i = 0; i sz; ++i) {
...
}
Would also suit me a lot better.
+ for ( i = 0, sz = blist.size(); i sz; ++i )
+ {
+ bibkeys.push_back(blist[i].first);
+ bibkeysInfo.push_back(blist[i].second);
+ }
+
sz = blist.size(); // remove const from the prev sz
for (int i = 0; i sz; ++i) {
...
}
The same "bugs" are done in other blaces as well.
I'll look for them in my code.
The comments can be looked at as nit-picking, but is more (IMO) a case
of good style and clearity.
And remember: const const const! (and that goes for all of you)
Found a strange one:
+ contents += clist_bib_-selection().operator[](i).operator[](1).get_text();
+}
Why can't that be written as "clist_bib-selection[i][1].get_text();" ?
+ lv_-getLyXFunc()-Dispatch( LFUN_CITATION_INSERT,
+ params.getAsString().c_str() );
Get rid of the c_str() to Dispatch.
+ string tmp, stext( search_string_ );
Please one variable one line!
string tmp;
string stext(searc_string_);
lv_-getLyXFunc()-Dispatch( LFUN_INDEX_INSERT,
params.getAsString().c_str() );
}
beware of c_str to Dispatch.
+ // update lists
+ if (toc_.size() 0)
+{
Use
// update lists
if (!toc_.empty()) {
instead.
+void Menubar::Pimpl::updateList(vectorBuffer::TocItem * toclist,
vectorListsHolder * pgui)
+{
Pass by reference instead. If const is possible use const.
This will go as bind argument later. As far as I know we cannot use
references as slot or bind arguments yet.
+ vectorpairstring,string names =
+viewable
+? Exporter::GetViewableFormats(owner_-buffer())
+: Exporter::GetExportableFormats(owner_-buffer());
+
+ for (vectorpairstring,string ::const_iterator cit = names.begin();
+ cit != names.end()
some typedef for vectorpairstring, string would be handy.
Lars, thank you very much for looking into the code! I'll scan the rest of
my code for these "bugs"
Marko
[patch] Re: even faster way to produce core dump
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 in the same spot? | | | | No, lyxfunc.C: line 656 | | | | So can you remove the c_str() in this line too? | | it doesn't help either. still dumps core. does it dump on your machine | too? I have not tried, I just fixed the class to dispatch. I'll leave the testing to you. pressing Esc didn't produce any core, but writing "cancel" in minibuffer did. The following patch fixes it. This patch contains some cleanup of the gnome frontend code too. Marko patch.disp.gz
Re: inset questions
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 small) dialog containing only a "choice of output" menu. No "Ok" or "Cancel" buttons are needed, I think. (Now I think of it, haven't I just defined a context-sensitive menu form?) It seems to me that "Cancel" is needed always. In this case, it will be the same for user as to close context-sensitive menu without selecting anything by pressing mouse button outside the menu area. Marko
Re: Lost math bindings
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 things as simple as possible. Going to a menu my expectation is to use the mouse and I am there much less often than in the middle of a doc, so the extra key to press is no problem M-"S-f" I would not like to see the math menu nuked. And LyX will be the only program I know to do that :). Actually, I know a lot of people who open menu and select menu item by keyboard only using M-f o, for example. Marko
Re: Lost math bindings
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 a lot of people who open menu and select menu item by keyboard only using M-f o, for example. - But LyX does not have rulers, tabs, doublespaces after periods either. And how many other programs have hollywood and broadway :) True. But in all programs with the menus I know (Gnome KDE ...), user can select the menu by M-character underlined in menu. We can just change _Math to M_ath or Mat_h and be consistent with the mentioned GUI. Marko
gnome: FormCitation
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. Second, it allows to change the order of citations or remove them one-by-one. The mode is selected by user or automatically if now citations were found in the inset. This patch contains a small addition to gnome menu. Now it supports large TOCs. Marko formcitation.gnome.patch.gz formcitation.gnome.newfiles.tar.gz
Re: inset questions
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 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 small) dialog containing only a "choice of output" menu. No "Ok" or "Cancel" buttons are needed, I think. (Now I think of it, haven't I just defined a context-sensitive menu form?) It seems to me that "Cancel" is needed always. In this case, it will be the same for user as to close context-sensitive menu without selecting anything by pressing mouse button outside the menu area. A CSM should only be visible while the mouse button is held down. Once the mouse is released the menu closes. If the mouse was over a menu entry that menu entry's action takes place. If the mouse cursor was outside the menu borders nothing happens. You don't need a cancel button and CSM's shouldn't be opened with one click and operated with another. We don't need "Cancel" in CSM, but we need it if we want to emulate CSM with a dialog. Marko
Re: Gnome Toolbar: which interface to use?
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 is not modal (at least in xforms) and can be kept open. - toolbar is not a good tool when you need something often, but keybindings are better. We have keybindings for typewriter/sans-serif. Toolbars are good for displaying states (layout mode for example) and for rarely used functions. However, since it is possible to build up toolbars similar to menus by using multiple toolbars and drop-down lists, it will be not wise to limit users with one toolbar. Wouldn't that be logical to use the same syntax in lib/ui/default.ui file for menus and toolbars? BTW, is it possible to have Layouts (xforms toolbar) in menu? Marko
Re: current cvs compile fails
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 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/lib/glib/include -I/usr/X11R6/include -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -Wconversion -Winline -c tabular.C tabular.C:97: warning: #warning Jürgen, can you make it the other way round. So that copy assignment depends on the copy constructor and not the other way. (Lgb) tabular.C:476: warning: #warning Jürgen, should the types change? (Lgb) tabular.C:624: warning: #warning Please fix align type. (Lgb) tabular.C:635: warning: #warning Please fix align type. (Lgb) tabular.C:645: warning: #warning Please fix align type. (Lgb) tabular.C:686: warning: #warning Fix the "what" type. (Lgb) tabular.C:749: warning: #warning Fix return type. (Lgb) tabular.C:759: warning: #warning Fix return type. (Lgb) tabular.C:1630: warning: #warning Should what be bool? (Lgb) tabular.C:1746: warning: #warning should the return type change? (Lgb) tabular.C:1897: warning: #warning should this return a bool? (Lgb) tabular.C:1929: warning: #warning should this return a bool? (Lgb) In file included from /usr/local/egcs/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3/map:31, from language.h:19, from lyxfont.h:22, from insets/lyxinset.h:23, from insets/insettext.h:22, from tabular.h:24, from tabular.C:22: /usr/local/egcs/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3/stl_tree.h: In function `int __black_count(_Rb_tree_node_base *, _Rb_tree_node_base *)': /usr/local/egcs/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3/stl_tree.h:1258: warning: can't inline call to `int __black_count(_Rb_tree_node_base *, _Rb_tree_node_base *)' /usr/local/egcs/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3/stl_tree.h:1266: warning: called from here tabular.C: At top level: tabular.C:623: prototype for `bool LyXTabular::SetAlignment(int, LyXAlignment, bool)' does not match any in class `LyXTabular' tabular.h:221: candidate is: bool LyXTabular::SetAlignment(int, char, bool = false) On Thu, 28 Sep 2000, Angus Leeming wrote: No fancy warnings this time; just errors! Angus cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../src/cheaders -I/usr/local/include -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -MD -c insettabular.C -o insettabular.ocxx: Warning: insettabular.h, line 148: "void InsetTabular::GetCursorPos(BufferView *, unsigned long , unsigned long ) const" does not match "UpdatableInset::GetCursorPos" -- virtual function override intended? void GetCursorPos(BufferView *, unsigned long x, -^ cxx: Warning: insettabular.C, line 826: unrecognized preprocessing directive #warning Jürgen, have a look. Is this correct? (Lgb) -^ cxx: Error: insettabular.C, line 1252: a value of type "LyXTabular::VAlignment" cannot be assigned to an entity of type "LyXAlignment" setAlign=LyXTabular::LYX_VALIGN_TOP; --^ cxx: Error: insettabular.C, line 1256: a value of type "LyXTabular::VAlignment" cannot be assigned to an entity of type "LyXAlignment" setAlign=LyXTabular::LYX_VALIGN_BOTTOM; --^ cxx: Error: insettabular.C, line 1260: a value of type "LyXTabular::VAlignment" cannot be assigned to an entity of type "LyXAlignment" setAlign=LyXTabular::LYX_VALIGN_CENTER; --^ cxx: Info: 3 errors detected in the compilation of "insettabular.C". make: *** [insettabular.lo] Error 1
gnome: FormRef and FormError
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 formcitation.gnome.patch.gz formref.gnome.newfiles.tar.gz
Re: gnome: FormRef and FormError
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" area to make the work with references as fast Marko and convenient as possible and scanning error messages less Marko disturbing. Marko, are you sure you posted the right patches? You sent formcitation.gnome.patch.gz, which is an old already applied patch, and formref.gnome.newfiles.tar.gz. Sorry! I hope this time I am sending the right one. Marko formref.gnome.newfiles.tar.gz formref.gnome.patch.gz
Re: gnome: FormRef and FormError
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
gnome cleanup patch
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. Marko gnome.cleanup.patch.gz
Re: New Menu::expand method in menu backend
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 few questions, though: I think that my suggestion is a little bit cleaner. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. It has been claimed that the Refs menu is redundant, and I think that I agree. The whole purpose of this menu was a fast way for adding references, but using the new reference dialog (with the keyboard) is as fast as using the Refs menu. True, you can add/edit the reference quite fast with the dialog. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 label11...label21 It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. Does it mean that if you want to insert "page reference" after plain reference you will have to navigate through the menus, select "Insert page reference" and since the menu will close, you will have to navigate once more and then select the reference. The same holds for just "Goto ref". It seems to me that it is not expected that you have to go to the menu twice for an action. For me it is much more confusing than to navigate through menus by selecting what I want to do with the reference and then selecting particular reference (as it is now) :). Marko
Re: new xforms patch
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 code some dialogs and then compose the base classes looking into the implementation of several dialogs. This approach helped me to learn LyX and its requirements to compose base classes better. Second, all the dialogs which use "action" area have to be constructed on "fly" and change/update on the basis of user input. This makes using the dialogs easier, faster and much more fun, but coding ... well, you mentioned a size of the code :). There's also a few connections being made to update that aren't used (since update is empty) is this a temporary thing? (ie. do you plan on filling in some more code?) Most (even it seems to me that all) of these empty update functions are in "action" area dialogs. My latest patch connects updateBufferDependent to hide function. The reasons for it are as follows. If I understand correctly "update" is called when user opens a new document or changes the document. If this is true then for "action" area dialogs the update signal has to close the dialog since user is not interested in this action anymore :). At least it is easier to implement than keeping action area state for each document... There also appears to be a few places where a new update_something() function exists that could be used as update() and an update connection would then make sense. the quick grep for update in gnome sources showed only updateButtons in FormCitation that might look as a candidate for an update connection and which doesn't use it. However, updateButtons is used to track user input in FormCitation dialog and has nothing to do with change of the document. 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 defined? I am just used to call NULL a pointer that might lead to a core dump. I haven't looked into gnome conventions recently, but if you will give me a good reason to use integer 0 insted of NULL then I can change everywhere NULL to this particular integer value. BTW, I've said it before but I'll say it again anyway since it's friday: You don't have to call your files by the same name as the xforms code. I would have expected KDE for example to use DialogX myself -- or whatever naming convention exists for apps using a particular toolkit. Unfortunately, the gnome frontend is still lagging behind xforms. That's why it is easier to use the same names for the dialogs since it gives a good overview of the state of the port. Finally, it is nice to remember roots of LyX when everyone will switch to Gnomified version :). [...] There that's probably pissed nearly all the GUII devvies off. No way! It is very nice to have someone who is looking into the code. It is a first step to make this effort in porting LyX to gnome or kde from one-man project to dynamic project full of discussions/suggestions/implementations as the rest of LyX is. Actually, this is a reason why I would not like to have cvs-write access anytime soon. This guarantees that the code was working at least in two occasions and someone has at least just scanned the patch. Have a nice Friday 13th, Enjoy it too. Marko
Re: gnome cleanup patch
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
Re: New Menu::expand method in menu backend
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". However, maybe it is better to ask lyx-users@... first? I don't know what are the procedures of removing the features in LyX... Marko
Re: gnome cleanup patch
this version should work/compile just fine with new updateBufferXXX. Marko gnome.cleanup.2.patch.gz
Re: new xforms patch
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 defined? Marko I am just used to call NULL a pointer that might lead to a core Marko dump. I haven't looked into gnome conventions recently, but if Marko you will give me a good reason to use integer 0 insted of NULL Marko then I can change everywhere NULL to this particular integer Marko value. I could not find a reference to it anywhere, but I am sure Lars will be able to remind us why NULL is evil :) I'll supply one: NULL is a C'ism while 0 is C++. That's why I asked where NULL is defined. I suspect you are getting NULL from a C header file where it is probably defined as (void*)0 or something similar -- if you write 0 the C++ compiler will consider it to be static_castWhateverType *(0) and the 0 will therefore have an _appropriate_ type. If you were being tricky and setting all your dynamic memory to 0x0a or some other marker to help detect uninitialised memory I could understand you using something other than 0 to initialise a pointer (provided the rest of your code was full of Assert()'s checking the pointers against that value). In C++ if you mean zero you write 0. IIRC, this is mentioned in both the C++ FAQ and Effective C++. I see. I'll submit a patch as soon as I'll be back in my office (in a week or so). Marko
Re: Problem compiling lyx with gnome on a linux box (fwd)
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 with ./configure --with-frontend=gnome [...] checking for gtk-config... (cached) /usr/bin/gtk-config checking for GTK - version = 1.2.0... yes [...] gtk is well detected ... but checking for IceConnectionNumber in -lICE... yes checking for XOpenIM... yes checking for /usr/bin/gtkmm-config checking for GTK-- - version = 1.2.1... no *** Could not run GTK-- test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK-- was incorrectly installed *** or that you have moved GTK-- since it was installed. In the latter case, you *** may want to edit the gtkmm-config script: /usr/bin/gtkmm-config configure: error: Cannot find GTK--: Please install Version 1.2.1+ [yann@venusia lyx-1.1.6pre1]$ rpm -qa | grep gtk gtk+10-1.0.6-6 gtk-engines-0.7-1 pygtk-0.6.2-2 gtk+-1.2.8-1 gtk+-devel-1.2.8-1 [yann@venusia lyx-1.1.6pre1]$ i've got no gtkmm-config program in my linux box. where is the problem. did i forgot something on more time ;-) Hi Yann! indeed, you've forgotten to install some required libraries. LyX gnome port requires three additional libraries: gtk--, gnome--, and libsigc++. You can obtain these fine libraries from gtk-- : http://gtkmm.sourceforge.net/ (take the latest one) gnome--: http://gtkmm.sourceforge.net/ (take the latest one,1.1.12(beta)) libsigc++: http://libsigc.sourceforge.net/ Then run configure with the following options: --with-frontend=gnome --without-included-libsigc --disable-sigctest . Enjoy the partly gnomefied LyX! Marko
gnome: cleanup and update() to updateSlot()
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 hierarchy among gnome frontend classes. Marko patch.gnome.29.10.00.gz
Re: gnome: cleanup and update() to updateSlot()
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 appropriate. Marko It seems that DialogBase is changing its methods quite often Marko which is one more good reason to establish class hierarchy Marko among gnome frontend classes. Hi, Is there a particular reason why you use: if (search_text_ != 0) search_text_-save_history(); instead of if (search_text_) search_text_-save_history(); The second form is used commonly in LyX code. That what hapens if you replace NULL with 0. I'll replace "if (search_text_ != 0) " with "if (search_text_)" in the code later. Marko
gnome: update patch
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
Re: Fwd: Re: Mandrake and KDe frontend
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 dynamic menus/toolbars is the way they are supposed to
handle the changes in LyXFunc values. I think that the same problem will
show up much worser in server-client architecture (or client will have to
ask for the complete status update after any change of the document which
may hang your machine/network ...). This problem has been discussed
earlier and it has been demonstrated that it is relatively easy to resolve
this problem using signals that are emitted if some function state/value
changes. I guess that this mechanism has to be implemented anyway to allow
LyX to display dynamic content in any GUI.
[...]
Concerning toolbars, I have the following scheme in mind:
1/ give name to toolbars and have several of them (like menus): "main"
"math" "table". In fact it may be possible to use the same backend for
toolbar and menus, although I am not sure what the advantage will be.
2/ In the code, add some showToolbar("math")/hideToolbar("math")
3/ Let the front end do what it wants with it :)
Actually, the current implementation of menus may be utilized to implement
toolbars. We had a discussion on this topic before and I've even submitted
a screenshot of lyx gnome frontend with the toolbar corresponding to main
menu :).
Marko
even faster way to produce core dump
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 some problem with string: debugger shows line 301 in src/lyxfunc.C Marko
Re: Can we remove the code for references in menus?
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
John current examples are just about buffer switches/opens/closes.
John Why not call them bufferOpened(), etc. ? Why the vague
John "update()" ?
It might be: "the cursor moved, maybe you should update the checkboxes
for font settings" or anything. In fact it is called when LyX waits
for input, so maybe nothing intresting happened, but I believe the
computational cost is small. Now, I do not think that we should add
checks and signals all over the kernel code to cover all possibilities.
This is the way it is implemented in Gnome frontend. As far as I can
see the overhead is indeed minimal. However, I haven't profiled it...
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 not
John just tell it what changed ?
What I envision is enhancing the toolbar code to have several named
toolbars, like current menus. Then add methods show/hide for named
toolbars. The toolbars would have generic names like "math",
"tabular", etc. A dumb implementation like xforms could chose to
ignore these calls. Better ones would do the right thing.
Another possibility is to use exactly the same interface for toolbar and
menubar. Then the set of toolbars will be presented by first level
submenus, buttons in the toolbars --- by commands in submenus, and
comboboxen by sub-submenus. Easy and as configurable as menubars
are. Kernel will just call toolbar-update() and menubar-update() and
there will be only one toolbar object to call by the kernel.
[...]
John I don't see how you could do this in a nice way, without
John essentially implementing my suggested scheme :
John Signal0void enteredTableArea;
toolbar-show("tabular");
do you really want to see flashing toolbars depending on where you are in
the document? I think that usually people fix the toolbars and these
toolbars don't change much. I might be wrong --- there are no toolbars in
my gnu emacs at all.
_except_ for the TOC case, which deserves a special treatment with
some signals. This is another reason why I want to remove the refs
stuff, which is the other special case.
Maybe TOC, LOF, LOT, ... need a new signal (updateLists)?
[...]
Actually, there are things that I do not really know how to handle in
toolbars:
- combox: currently, there is only one possible combox, the layout
combox. Will we need more of them, and which ones?
You might want to have any command in the combox (emphasize, \Large, TOC,
style). This is easy to implement using menu structure.
Also, in menus, there is the problem of updating intelligently the
TOC (because it could cost time to do it too often). However this
problem would also arise if you had complete control on the menus. A
solution has to be devised, maybe with signals.
Signal would be nice.
Marko
Re: Can we remove the code for references in menus?
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 not John just tell it what changed ? What I envision is enhancing the toolbar code to have several named toolbars, like current menus. Then add methods show/hide for named toolbars. The toolbars would have generic names like "math", "tabular", etc. A dumb implementation like xforms could chose to ignore these calls. Better ones would do the right thing. Another possibility is to use exactly the same interface for toolbar and menubar. Or toolbar and dialogs as I keep saying... We can also use dialogs interface for menubar too. The only difference which I see in current implementation of dialogs VS menubar is that menubar is user-configurable and dialogs are hard-coded. I guess, we would like to keep the user settings for toolbars too. If we treat toolbars and menubars as dialogs then the only parameter which is required to build these objects is menubar or toolbar name defined in .lyxrc files. This name can be passed by InsetCommand, if I am not missing something. [...] do you really want to see flashing toolbars depending on where you are in the document? I think that usually people fix the toolbars and these toolbars don't change much. I might be wrong --- there are no toolbars in my gnu emacs at all. You all seem to have missed the fact that tables already have an update signal for the dialog and that triggers changes in the dialog when the cursor moves around the cells. A table toolbar is just a different form of this dialog and so there is no point in adding a toolbar specific signal when the table dialog one already exists. That's part of the reason why I keep trying to get you blokes to see that toolbars are just the same as dialogs. They are built differently [initialisation] but they look the same to the kernel and can share the same signals. _except_ for the TOC case, which deserves a special treatment with some signals. This is another reason why I want to remove the refs stuff, which is the other special case. Maybe TOC, LOF, LOT, ... need a new signal (updateLists)? Why all lists? If a figure inset is changed then an LOF-signal could be sent and so on. Even better. Also, in menus, there is the problem of updating intelligently the TOC (because it could cost time to do it too often). However this problem would also arise if you had complete control on the menus. A solution has to be devised, maybe with signals. Signal would be nice. I still think this should be triggered by the frontend -- sure I know the tear-off menu arguement and there is probably a need for a specific signal for that but you should only need to update the TOC when it's accessed. A torn-off menu however would want to be updated by a signal (since it would look like the existing TOC dialog). There is another silly example when this signal is needed --- one might have TOC in the toolbar with chapters showing up as a buttons. I am not sure who would like to have this feature, but the point is that kernel has no idea how the lists are presented to the user (dialog, menu, toolbar, or just written to the serial port). In the case of TOC written to the serial port we even don't have any "Refresh" button to press or the frontend will have to take care for processing input from serial console too. Marko
Re: The LyX licence
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 later. best wishes, marko On Tue, 22 Feb 2005, Angus Leeming wrote: Dear all, please excuse the personal email, but I'm trying to do something about the messy state of the LyX licence and need your help. LyX is currently licenced under the GPL with a huge hole blowing it wide apart so that it could be linked against the closed source XForms library. See http://www.lyx.org/about/license.php3. Legal opinion has it that this exception does not apply only to the XForms library. Instead, anything and everything is allowed to link against the LyX source code, defeating the whole point and purpose of the GPL. Moreover, the exception is no longer needed as XForms (and indeed Qt) are available under the GPL. To make a messy situation even messier, it's not even certain whether the current license is valid at all, as the necessary permissions may not have been obtained before the change was made to the original GPL. In light of all this, I'm asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt: The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later. so that we can have a permanent record of those people who have contributed code to LyX and who are happy for this code to be licenced under the GPL. Kind regards, Angus ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent record of your response. pps. in case you're wondering where I got your email address from: it's listed in the LyX hall of fame: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/CREDITS?rev=1.53content-type=text/vnd.viewcvs-markup Equivalent URL: http://tinyurl.com/5nqhs
Re: The LyX licence
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 later." best wishes, marko On Tue, 22 Feb 2005, Angus Leeming wrote: Dear all, please excuse the personal email, but I'm trying to do something about the messy state of the LyX licence and need your help. LyX is currently licenced under the GPL with a huge hole blowing it wide apart so that it could be linked against the closed source XForms library. See http://www.lyx.org/about/license.php3. Legal opinion has it that this exception does not apply only to the XForms library. Instead, anything and everything is allowed to link against the LyX source code, defeating the whole point and purpose of the GPL. Moreover, the exception is no longer needed as XForms (and indeed Qt) are available under the GPL. To make a messy situation even messier, it's not even certain whether the current license is valid at all, as the necessary permissions may not have been obtained before the change was made to the original GPL. In light of all this, I'm asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt: "The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later." so that we can have a permanent record of those people who have contributed code to LyX and who are happy for this code to be licenced under the GPL. Kind regards, Angus ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent record of your response. pps. in case you're wondering where I got your email address from: it's listed in the LyX hall of fame: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/CREDITS?rev=1.53=text/vnd.viewcvs-markup Equivalent URL: http://tinyurl.com/5nqhs
kde frontend: LyXFunc or LyXView
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 argument in KDE frontend (src/frontends/kde/Dialogs.C). Error message: # ./configure --with-frontend=kde ... # make ... g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../.. -I../../.. -I/usr/lib/qt-1.44/include -I/usr/include/kde -I/usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/Dialogs.pp -c Dialogs.C -o Dialogs.o Dialogs.C:13: prototype for `Dialogs::Dialogs(class LyXFunc *)' does not match any in class `Dialogs' ../../../src/frontends/Dialogs.h:119: candidates are: Dialogs::Dialogs(class Dialogs &) ../../../src/frontends/Dialogs.h:117: Dialogs::Dialogs() ../../../src/frontends/Dialogs.h:55: Dialogs::Dialogs(class LyXView *) Regards, Marko
Re: kde frontend: LyXFunc or LyXView
> 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 should be
>
> Dialogs::Dialogs(LyXView * lv)
> {
> dialogs_.push_back(new FormCopyright(lv, this));
> dialogs_.push_back(new FormPrint(lv, this));
> dialogs_.push_back(new FormPreferences(lv, this));
>
> // reduce the number of connections needed in
> // dialogs by a simple connection here.
> hideAll.connect(hideBufferDependent.slot());
> }
>
> Note, however, that this code won't compile either as no Print and
> Preferences dialogs for kde. Commenting them out will allow the code to compile
> (and maybe even link??) but the resulting executable will not have these
> dialogs. Seems a bit pointless, no?
>
> If, of course, you wish to write the missing dialogs...
>
> Angus
>
The attached small patch allows to compile kde frontend. The resulting
executable misses FormPrint and FormPreferences dialogs but shows
FormCopyright using kde libs.
Marko
patch.gz
GTK/Gnome frontend and string class
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 Gnome libraries). GTK-- and GNOME-- rely on STL string class which is not good enough for LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). This is a problem since in LyX string class is typedefed to lyxstring and the resulting code does not link properly with GTK-- and GNOME-- libraries. The following solutions to this conflict between GNOME/Gtk and LyX popped into my mind: 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers 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). 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this libraries with lyxstring. 4. Find better implementation of STL for Linux and use its string class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ is not good enough to compile LyX). Which of these (or any alternative) solutions should be used for LyX GTK/Gnome frontend? Regards, Marko
Re: GTK/Gnome frontend and string class
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 hope. > The lyxstring tries to be close to API compatible with std::string. Well, it should be possible to find API and libstdc++ compatible implementation. For example, instead of comparing string and char* directly (src/support/lstrings.C, lines 184 and 201), one can make temporary string object from char* and compare it with other string. It is not as effective implementation as the current one, but it will work just fine with libstdc++. It is hard for me to say how to re-implement the code in src/lyx_cb.C (line 1109) to make it compatible with libstdc++ since STL is very new to me. > | 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this > |libraries with lyxstring. > > Isn't Gtk-- and Gnome--- a bit large for that? Yes, it is. However, we can include scripts that build Gtk--/Gnome-- automatically with lyxstring instead of std::string. At least, the resulting frontend code should work fine and we can drop it later (after release of libstdc++-v3). > Can we have an interim solution where we use char* to communicate > between lyx-core and the gtk frontend? When Gcc 2.96 is released it > will hopefully be with the new libstdc++-v3 library, and then there > will be no problems. This will require isolation of Gtk/Gnome frontend code from the rest of the LyX code. For example, it will be not possible to include even src/frontend/Dialogs.h directly from the frontend implementation since it contains "#include "LString.h"". I think such solution will lead to unnecessary code in LyX. Marko
GTK/Gnome frontend elementary support
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 platform with good STL string implementation. In such case you need standard gtk, gnome, libsigc++ , gtk-- and gnome-- libraries. On my platform (redhat linux 6.1, egcs 1.1.2) LyX uses LyX string class instead of STL string. To use gtk-- and gnome-- with LyX I recompiled these libraries after replacing "#include " by "#include "LString.h"" in the source files of the libraries. To make our life easier I've written two small scripts that patch gtk-- and gnome-- libraries and compile them. Please note that running these scripts is DANGEROUS since it may change your source files. The following are instructions for getting Gtk/Gnome frontend running in the platforms that lack good STL string implementation (it worked on my platform): * install Gtk, Gnome, and libsigc++ * download gtkmm-1.2.1.tar.gz and gnomemm-1.1.10.tar.gz from http://gtkmm.sourceforge.net/download.html (click "sourceforge download area" on this page) * create a new directory and copy gtkmm-1.2.1.tar.gz, gnomemm-1.1.10.tar.gz, lyxgtk.sh, and str2lyxstr.sh to this directory (lyxgtk.sh and str2lyxstr.sh are attached to this e-mail) * cd to this directory * read and edit script lyxgtk.sh (set source and install directories) * run script lyxgtk.sh * include directory with installed new gtk and gnome libs to PATH and LD_LIBRARY_PATH as first directories (subdirs bin and lib, respectively). * cd to lyx source directory * run autogen.sh * run configure with the following options: --with-frontend=gtk --without-included-libsigc --disable-sigctest --with-gnomemm-config-path=NEW_GNOMEMM_LIB/lib/gnomemmConf.sh --disable-gtkmmtest * run make Please note, that compiled Gtk--/Gnome-- libraries are usable only with LyX. Finally, to make configure script working I had to disable AC_LANG_CPLUSPLUS in configure.in (line 66). Otherwise gnome configuration scripts were not working properly. It will be very nice if someone with good knowledge of configure.in magic would take a look on this problem. Regards, Marko #!/bin/bash # This script is DANGEROUS! It replaces # "#include " with "#include "LString.h"" in the files in # current directory (recursively!). This can change YOUR source files. # Use it at your own risk. FILELISTCC=`rgrep -r -l "#include " . | grep "\.cc"` FILELISTH=`rgrep -r -l "#include " . | grep "\.h"` FILELISTGEN=`rgrep -r -l "#include " . | grep "\.gen_"` for i in $FILELISTCC $FILELISTH $FILELISTGEN; do cat $i | sed -e 's/#include /#include "LString.h"/g' > .tmpfile mv .tmpfile $i done #!/bin/bash # This script is DANGEROUS! It uses script srt2lyxstr.sh to replace # "#include " with "#include "LString.h"". This can change YOUR source files. # Use it at your own risk. # extracting GNOME-- and GTK-- tar zxvf gnomemm-1.1.10.tar.gz tar zxvf gtkmm-1.2.1.tar.gz # Please specify the directories with GTK--, GNOME--, LyX source, and the directory # to which new GTK--/GNOME-- libraries should be installed. GTKMMDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/gtkmm-1.2.1 GNOMEMMDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/gnomemm-1.1.10 LIBINSTALLDIR=/home/users/markov/cpp-files/lyx/lyx-gtk/root LYXDIR=/home/users/markov/cpp-files/lyx/lyx-devel # Please note that script creates temporary directory $GTKMMDIR/../.tmpdir . # Change the script if this is not acceptable for you. mkdir $LIBINSTALLDIR export MAKE="make" export CXXFLAGS="-DUSE_INCLUDED_STRING -I$LYXDIR/src" CURRDIR=`pwd` STR2LYXSTR=$CURRDIR/str2lyxstr.sh # gtkmm cd $GTKMMDIR ./configure --prefix=$LIBINSTALLDIR echo -e "all: \ninstall: \n" > gdk--/tests/Makefile mv src/gtkmmproc ../.tmpdir $STR2LYXSTR mv ../.tmpdir src/gtkmmproc make make install cd $CURRDIR # gnomemm export PATH=$LIBINSTALLDIR/bin:$PATH cd $GNOMEMMDIR ./configure --prefix=$LIBINSTALLDIR --disable-gtkmmtest $STR2LYXSTR make make install cp src/gnomemmConf.sh $LIBINSTALLDIR/lib cd $CURRDIR gnome-add.tar.gz gnome-patch.gz
Re: GTK/Gnome frontend elementary support
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 frontend works fine here. Current cvs should contain new directories config/gnome src/frontend/gtk Please check, whether you have these directories in your local copy and whether autogen.sh script contains a huge line with "for fil in config/lyxinclude.m4 config/libtool.m4 config/gettext.m4 config/lcmessage.m4 config/progtest.m4 config/sigc++.m4 config/kde.m4 confi g/gnome/aclocal-include.m4 config/gnome/gnome-print-check.m4 ..." Marko
Re: GTK/Gnome frontend elementary support
> 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 tar.gz and small patch to autogen.sh adds 1 .m4 script (config/gnome/gtk.m4). I've tried to generate configure script with minimal amount of files in /usr/share/aclocal and it worked now in my system. Sorry for the mess. Marko patch.gtk.m4.add.gz config.gnome.tar.gz
Re: GTK/Gnome frontend elementary support
> 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++ compiler. If the gnome scripts are broken > with C++, they should be fixed. What are the errors? I cannot test, > since I do not have gnome installed here. Well, it seems that script gtk.m4 fails to compile a small gtk program with AC_LANG_CPLUSPLUS. When I inserted AC_LANG_C before AC_TRY_RUN (gnome/gtk.m4, line 65) and AC_LANG_CPLUSPLUS at the end of this script, the program was compiled. However, the configure script produced slightly different Makefile (one CPPFLAGS option was missing). Thus, to resolve this problem one needs to run AC_TRY_RUN with AC_LANG_C and somehow keep the configuration of AC_LANG_CPLUSPLUS. I don't know how to do it. > PS: Marko, are you on the lyx-devel list? yes, almost for an hour already :). Marko
Re: GTK/Gnome frontend elementary support
> 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
Re: GTK/Gnome frontend elementary support
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 reproduce the problem. Marko
Re: GTK/Gnome frontend elementary support
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 config/gnome/gtk.m4). If we add line CXXFLAGS="$CXXFLAGS $GTK_CFLAGS" after line 58 then this test is passed. Marko
