Re: GUII status (was Re: patch InsetInfo->InsetNote)
On Wed, 27 Sep 2000, John Levon wrote: > Ok, you're right. The status thing was just a first stab at something, and > it indeed does seem it's not adequate. So can you give a complete list of > the states you think should exist and what they mean ? I ask you only > because you have better idea of porting process than me I basically agree with the definitions you wrote earlier in thread but I don't have that email handy so I'll quickly redefine them here: Completed In the codebase and working. No significant deficiencies. Further work may be happening but only of a minor nature. In Progress In the codebase but still undergoing major development work. Either incomplete functionality or the dialog design/layout is undergoing major revision. Pending Someone has started working on this dialog although no code has been added to the codebase yet. Find another dialog to work on as we are expecting a patch anytime soon. Maybe there was another state in your previous email -- I can't remember. It would perhaps be a good idea to keep a full list of all the current dialogs and any new ones but mark dialogs that will be removed or merged appropriately. That is, if a dialog currently exists but will be replaced by a minibuffer thingy or a collapsible inset we should mark it as such. This would also allow us to specify differences between different ports. If I understand it correctly GNOME currently uses a buffer-dialog for Citation while xforms uses a dialog. We should perhaps distinguish between these also -- then again we're getting a bit nitpicky to be define what style is used for each port. Just making it clear which dialogs are planned for merging into others or for implementation in some other manner would at least ensure that some new helper doesn't run off and port something we're planning on doing without a dialog. Likewise, new dialogs should be listed with a link to either an appropriate thread in the mail archive or a description page. Stuff like the much needed and much talked about reLyX dialog. Allan. (ARRae)
cvs compile errors
Attached Making all in insets make[3]: Entering directory `/usr/local/garst/lyx-devel/src/insets' /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -Wconversion -Winline -c insettabular.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -W -Wall -Wconversion -Winline -Wp,-MD,.deps/insettabular.pp -c insettabular.C -o insettabular.o insettabular.C:826: warning: #warning Jürgen, have a look. Is this correct? (Lgb) In file included from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/include/g++/map:31, from ../../src/language.h:19, from ../../src/lyxfont.h:22, from lyxinset.h:23, from insettabular.h:52, from insettabular.C:22: /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/include/g++/stl_tree.h: In function `int __black_count(_Rb_tree_node_base *, _Rb_tree_node_base *)': /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/include/g++/stl_tree.h:1258: warning: can't inline call to `int __black_count(_Rb_tree_node_base *, _Rb_tree_node_base *)' /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/include/g++/stl_tree.h:1266: warning: called from here insettabular.C: In method `void InsetTabular::TabularFeatures(BufferView *, int, const string & = string())': insettabular.C:1252: conversion from `enum LyXTabular::VAlignment' to `enum LyXAlignment' insettabular.C:1256: conversion from `enum LyXTabular::VAlignment' to `enum LyXAlignment' insettabular.C:1260: conversion from `enum LyXTabular::VAlignment' to `enum LyXAlignment' make[3]: *** [insettabular.lo] Error 1 make[3]: Leaving directory `/usr/local/garst/lyx-devel/src/insets' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/garst/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/garst/lyx-devel/src' make: *** [all-recursive] Error 1
Re: Automatic dialogs
On Wed, 27 Sep 2000, John Levon wrote: > On Tue, 26 Sep 2000, Dekel Tsur wrote: > > > Designing a XForms dialog with fdesign was always a tedious task, > > which is why there are new features with no GUI support (for example: > > per-paragraph spacing). With the GUII, the situation is worse, as the GUI work > > is needed to be repeated 3 times (or even more in the future). I wouldn't have thought it was any more tedious than any other gui designer. But then again maybe I'm used to using it. > > So, I want to suggest a new approach for doing GUII dialogs: > > The dialogs structure and logiv will be defined by in a simple text file, > > and the dialogs will be built in run-time from these files. > > An example for this approach can be seen in Kaptain > > (http://www.hszk.bme.hu/~tz124/kaptain/) which is a "universal graphical > > front-end for command line programs". See > > http://www.hszk.bme.hu/~tz124/kaptain/docs/enscript.html > > for an example. > > > > In addition to easier maintenance, it will also add new abilities like the > > ability to define new insets with text files, and the ability to load > > various latex packages and set their parameters using a GUI dialog. > > > > I'm sceptical it would be simple to do this in a way that would suit all > the frontends. Remember Kaptain is for a specific GUI toolkit. In the early days of GUII (1997-98) several ideas were discussed. We decided we really wanted to work on LyX and not write our own cross-platform toolkit -- cross-platform toolkits at the time were fairly lame and that's argueably still the case: the best toolkit for Windows is still MFC like it or not. If you write a dialog design in some arbitrary format (eg. XML) you also need to write a dialog code generator for each and every platform we want to support. In other words a cross-platform toolkit. You can develop a cross-platform toolkit if you want but I'd rather you continued your excellent work on LyX (besides you know know more about multi-language documents than the rest of us put together). > And as Lars points out they shouldn't be the same design anyway - the > environments have different ways of doing things anyway Another good point. We're already seeing many interesting ideas springing up from the three existing toolkits and we've only got about half a dozen dialogs on all platforms so far. Allan. (ARRae)
Re: more cxx warnings for buffer.C
On 27 Sep 2000, Lars Gullik Bjønnes wrote: > Someone should send these fixes to the sigc++ team. Done. Allan. (ARRae)
Re: Bug in CVS
> #3 0x815ec58 in lyx::abort () at abort.C:9 > #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24 > ^ This causes > the crash If lyxstring really mimics std::string, the assert is correct: You should never call a string's constructor on a NULL pointer. I think until a day or two ago lyxstring behaved wrong by quietly accepting the NULL pointer and creating an empty string. The actual problem is here: > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 This line should read: return browser ? fl_get_browser_line(browser, sel) : string(); instead of: return browser ? fl_get_browser_line(browser, sel) : 0; Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Cxx warnings
cxx: Info: ../../src/cheaders/cstdlib, line 14: zero used for undefined
preprocessing identifier
#if _G_HAS_LABS
^
Complain to cxx...
cxx: Info: ../../src/lyxparagraph.h, line 228: conversion to
integral type of smaller size could lose data
size_type size() const { return text.size(); }
^
bla bla
cxx: Info: ../../src/font.h, line 59: conversion to integral type of smaller
size could lose data
return width(s.c_str(), s.length(), f);
^
fixed
cxx: Info: ../../src/font.h, line 64: conversion to integral type of smaller
size could lose data
return width(s, strlen(s), f);
^
fixed
cxx: Info: figinset.C, line 198: variable "wid1" was set but never
used
int wid1;
^
fixed
cxx: Info: figinset.C, line 321: conversion to integral type of smaller size
could lose data
xcol.red = 65535 * (i / (num * num)) / (num - 1);
-^
not much we can to about tis except add a specific cast to short...
fixed ... perhaps
cxx: Info: figinset.C, line 322: conversion to integral type of smaller size
could lose data
xcol.green = 65535 * ((i / num) % num) / (num - 1);
---^
ditto
cxx: Info: figinset.C, line 323: conversion to integral type of smaller size
could lose data
xcol.blue = 65535 * (i % num) / (num - 1);
--^
ditto
cxx: Info: figinset.C, line 363: conversion to integral type of smaller size
could lose data
xcol.red = xcol.green = xcol.blue = 65535 * i / (num - 1);
--^
ditto
cxx: Info: figinset.C, line 604: conversion to integral type of smaller size
could lose data
t1.str().size());
^
noting we can do...
cxx: Info: figinset.C, line 633: conversion to integral type of smaller size
could lose data
t3.str().size());
^
ditto
cxx: Info: figinset.C, line 1040: conversion to integral type of smaller
size could lose data
pain.text(int(x + 8), baseline - 4, msg, strlen(msg), font);
-^
fixed...hopefully
cxx: Info: figinset.C, line 1228: controlling expression is constant
fl_raise_form(form->Figure);
^
What does this mean?
cxx: Info: figinset.C, line 1271: conversion to integral type of smaller
size could lose data
angle, flags & (3|8));
--^
cxx: Info: figinset.C, line 1531: conversion to integral type of smaller
size could lose data
angle, flags & (3|8));
-^
cxx: Info: figinset.C, line 101: variable "bittable" was set but never used
static char bittable[256]; /* bit reversion table */
^
cxx: Info: figinset.C, line 107: variable "gs_num_pixels" was set but never
used
static int gs_num_pixels; // number of pixels allocated
---^
cxx: Info: figinset.C, line 109: variable "gs_gray" was set but never used
static bool gs_gray;// is grayscale?
^
Do do not really care about figinset.C, but I fixed some warnings in
this file anyway.
cxx: Info: insetbib.h, line 78: overloaded virtual function "Inset::display"
is only partially overridden in class "InsetBibtex"
class InsetBibtex : public InsetCommand {
--^
bs
cxx: Info: insetbib.C, line 192: controlling expression is constant
fl_raise_form(bibitem_form->bibitem_form);
^
explain
cxx: Info: insetbib.C, line 321: controlling expression is constant
fl_raise_form(bibitem_form->bibitem_form);
^
explain
cxx: Info: insetcite.C, line 42: conversion to integral type of smaller size
could lose data
int size = label.size() + 2 + key.size();
---^
fixed
cxx: Info: insetexternal.C, line 293: controlling expression is constant
fl_raise_form(form_external->form_external);
^
explain
cxx: Info: insetexternal.C, line 318: conversion to integral type of smaller
size could lose data
int pos1 = format.find(",");
---^
fixed
cxx: Info: insetexternal.C, line 320: conversion to integral type of smaller
size could lose data
int pos2 = format.find("\",\"", pos1);
---^
fixed
cx
Re: NoGUI LyX
On 27 Sep 2000, Jean-Marc Lasgouttes wrote: > and fix session (I have several bug reports in my mail folder which > depend on this). How about updating a known bug list and a todo list on the developers website for all to see? It will help development since we'll all be able to know what bugs are pending and what urgent todo stuff is waiting. It will also help new developers to find small tasks that they can start with. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Bug in CVS
When \kbmap is true, LyX crashes on startup. This bug is very recent (last day or two). The backtrace: #0 0x401e1a01 in kill () #1 0x401e1863 in gsignal () #2 0x401e28c5 in abort () #3 0x815ec58 in lyx::abort () at abort.C:9 #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24 ^ This causes the crash #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 #6 0x8088e5e in Intl::Keymap (this=0x81fb8a0, code=23) at intl.C:339 #7 0x8088cf3 in Intl::InitKeyMapper (this=0x81fb8a0, on=true) at intl.C:308 #8 0x80640bf in LyXView::init (this=0x81f3080) at LyXView.C:326 #9 0x8095aa1 in LyXGUI::init (this=0x81d3e40) at lyx_gui.C:251 #10 0x80971c6 in LyX::LyX (this=0xbb40, argc=0xbb60, argv=0xbb74) at ../src/lyx_main.C:105 #11 0x80b5fd6 in main (argc=1, argv=0xbb74) at ../src/main.C:40
Re: babel.sty, english.ldf
Juergen Vigna wrote: > > On 26-Sep-2000 Garst R. Reese wrote: > > > entries for canadien (french, note the e), and acadian, another french > > Do you like me to insert also acadian as "French Candian"? > > Jürgen Let me check with some acadian friends. It is distinct from French Canadian. Garst
Re: NoGUI LyX
Attached is a log file of ALL the warnings posted when compiling the insets directory with DEC cxx -w0. I've editted this file so that each warning occurs ONCE only. It should, therefore, be useful! Angus make.log.bz2
[PATCH] Complain about Qt2
This patch changes the kde m4 stuff so that if Qt2 is being picked up, configure will stop at the Qt setup rather than failing at the KDE compile, which is misleading. I have tested it with QTDIR=/usr/lib/qt-2.1.0 and QTDIR=/usr/lib/qt-1.4.5 as well as specifying --with-qt-dir=/usr/lib/qt-1.4.5 thanks john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb diff -u -r1.555 ChangeLog --- ChangeLog 2000/09/27 15:43:49 1.555 +++ ChangeLog 2000/09/27 16:43:01 @@ -1,3 +1,8 @@ +2000-09-27 John Levon <[EMAIL PROTECTED]> + + * config/kde.m4: make Qt fail immediately if + Qt2 is picked up + 2000-09-26 John Levon <[EMAIL PROTECTED]> * src/frontends/kde/Makefile.am: fix rule for diff -u -r1.4 kde.m4 --- config/kde.m4 2000/09/27 15:43:49 1.4 +++ config/kde.m4 2000/09/27 16:43:03 @@ -629,6 +629,24 @@ KDE_CHECK_QT_DIRECT(qt_libraries= ,[]) fi +dnl should check it's not Qt2, so it will fail now, rather than in KDE check + +SAVE_CXXFLAGS="$CXXFLAGS" +CXXFLAGS="$CXXFLAGS -I$qt_includes -L$qt_libraries" +AC_TRY_COMPILE([ +#include +], +[ +#if (QT_VERSION >= 200) +break_me_(\\\); +#endif +], +ac_qt_ok=yes, +ac_qt_ok=no +) +test "$ac_qt_ok" = no && AC_MSG_ERROR([Found Qt 2 - you must specify the path to the +Qt 1 headers and libraries]) +CXXFLAGS="$SAVE_CXXFLAGS" + AC_SUBST(qt_libraries) AC_SUBST(qt_includes)
src/ext_l10n.h
Er, whoops I added this to .cvsignore but I've just realised shouldn't this be removed from CVS altogether ? It is generated from autogen.sh so shouldn't it be removed from the CVS like configure etc. thanks john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: NoGUI LyX
Ok, so gui = false; is safe now:
--- schnipp -
Index: lyx_main.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
retrieving revision 1.50
diff -u -r1.50 lyx_main.C
--- lyx_main.C 2000/09/26 13:54:53 1.50
+++ lyx_main.C 2000/09/27 16:11:47
@@ -732,9 +732,6 @@
}
else
lyxerr << _("Missing command string after -x switch!") << endl;
-
- // Argh. Setting gui to false segfaults..
- //gui = false;
}
else if (arg == "-e" || arg == "--export") {
@@ -742,6 +739,7 @@
string type(argv[i+1]);
removeargs = 2;
batch_command = "buffer-export " + type;
+ gui = false;
} else
lyxerr << _("Missing file type [eg latex, "
"ps...] after ")
--- schnapp -
--
Andre' Poenitz [EMAIL PROTECTED]
Re: more cxx warnings for buffer.C
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> | cxx: Info: ../sigc++/slot.h, line 204: destructor for base | Lars> class | "SigC::Handle" is not | Lars> virtual | (D:basclsnondto) | class LIBSIGC_API | Lars> Connection:protected Handle | | Lars> ---^ | | Lars> The fix is probably what I posted in last mail. | | I'll try to see if I manage to fix it and send a message to sigc++ | people. | | Lars> ../../lyx-devel/src/support/block.h, line 48: conversion to | | Lars> integral type of smaller size could lose data (D:intconlosbit) | | Lars> detected during: | instantiation of "void block s>::operator=(const block &) | [with T=Bullet, s=4UL]" at | Lars> line 197 of | "../../lyx-devel/src/buffer.C" | implicit | Lars> generation of "BufferParams | &BufferParams::operator=(const | Lars> BufferParams &)" at line | 197 of "../../lyx-devel/src/buffer.C" | Lars> | arr[i] == b[i]; | ^ | | Lars> I don't quite understand tis one. | | Lars> ok so string::size_type is a long of some kind. I guess the most | Lars> correct type to use is string::size_type then. fixed | | Yes. This probably happens all over the code, in fact. | | Lars> Ok,... we go again... let me compile and commit first. | | OK. Do you want more of these, or have you had enough for today? After I have committed you can send me a new batch. Lgb
[larsbj@lyx.org (Lars Gullik Bjønnes)] CharArgs.txt
Character Arguments a.k.a. Logical Character Styles
Lars Gullik Bjønnes
<[EMAIL PROTECTED]>
1 Introduction
The use of fonts are at present a bit muddled in LyX. LyXFont does
not only hold basic font information but it also doubles for other
functionality as well. Basic font functionality is: size, shape, family
and series. In addition to this LyXFont supports a a couple of Logical
Character Styles (LCS): noun and emphasize. LyXFont also supports
underline, color, latex and language, I will dub those "physical styles".
Without saying anything more about it I want to split LyXFont into
two or three classes: TeXFont for basic font functionality, LCS for
logical styles and perhaps one for the Physical styles([footnote] We
need to decide if we want these physical styles to be in the TeXFont
or not.) . LyXFont will not disapear, but rather be changed into a container
for the other font classes and responsible for outputing the correct
- minimal - code for the underlying format([footnote] latex, linuxdoc
or docbook, or other supported formats.) . The rest of this document
and of this introdoction will be on the topic of LCS only.
We want to be able to support user defined LCS, so that the logical
structure of the document will be better. This will make LyX taken
advantage of the method used by LaTeX and other conceptual markup
languages. Some of these even need LCS to function properly, i.e.
DocBook. With LCS the user can create logical styles such as "first-name",
"car-brand" or "programming-language". For each of these styles the
user will be able to set the font to use, or for more advanced/experienced
users the actual LaTeX code to use for the style can be provided.
One of the nice things with LCS will then be that to change the visual
apparence of "programming-language" for example, will need no change
to the document proper, but only a change of the definition of the
LCS.
2 Implementation
The implementation of LCS will be surprisingly simple and will be possible
with only small changes to the rest of the LyX code. The LCS struct
will look basically like this:
struct LCS {
enum Type {
font,
command
};
Type type;
string logical_style_name;
TeXFont style_font;
string style_command;
};
It is possible that this struct will be reference counted([footnote] Then
the TeXFont will be reference counted too.) , but this is an implemetation
detail. The LCS struct will be stored in stl containers, most likely
a std::map will be used where the key is the logical_style_name.
We can have global or document local containers for these. LCS used
will be stored in the document. The TeXFont is the visual appearence
of the LCS.
3 User Interface
We need a user interface that will be easy for the user to use, and
easier and quicker to use than hardcoded font changes. LCS are after
all the preferred way.
3.1 Creating LCS
There will be a dialog where the user can set the name of the logical
style as well as the font to use for it. It will also be possible
to use the LCS command style where the user can provide the name of
the command used for the LCS([footnote] What about different documents
formats? Can this be handled in a nice way?) , the user has to provide
the actual command, either in the preamble or as part of LaTeX or
an addon package. Emph and noun will use this method. The storage
will be in some configuration file, perhaps .lyxrc.
When creating a LCS the user will be able to choose if this is to be
user global([footnote] This mean available for all documents of a
single user.) or document local([footnote] Only available to this document.) .
The system administrator can also choose to create LCS for use by
all LyX users on the system.
3.2 Setting LCS
The basic method of setting a LCS will be to mark the region of the
text that fullfills the LCS criteria. E.g. for the "first-name" style
I will mark "Lars Gullik", and then check "First Name" in the LCS
drop down list. It should perhaps also be possible to do it like other
font setting now.
3.3 Visualization
This will probably be the hard part. How should the use of logical
styles be visualized on screen? Begin-end dots? Different background
color? Drawn inside a box? A note in the minibuffer only? A line on
top of the LCS string? For the moment this last one seems best to
me, but it is rather intrusive on the display and might very well
clutter the screen too much.
4 Unresolved Issues
How will this affect LTR, if at all?
Re: more cxx warnings for buffer.C
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | cxx: Info: ../sigc++/slot.h, line 204: destructor for base Lars> class | "SigC::Handle" is not Lars> virtual | (D:basclsnondto) | class LIBSIGC_API Lars> Connection:protected Handle | Lars> ---^ Lars> The fix is probably what I posted in last mail. I'll try to see if I manage to fix it and send a message to sigc++ people. Lars> ../../lyx-devel/src/support/block.h, line 48: conversion to | Lars> integral type of smaller size could lose data (D:intconlosbit) | Lars> detected during: | instantiation of "void block s>::operator=(const block &) | [with T=Bullet, s=4UL]" at Lars> line 197 of | "../../lyx-devel/src/buffer.C" | implicit Lars> generation of "BufferParams | &BufferParams::operator=(const Lars> BufferParams &)" at line | 197 of "../../lyx-devel/src/buffer.C" Lars> | arr[i] == b[i]; | ^ Lars> I don't quite understand tis one. Lars> ok so string::size_type is a long of some kind. I guess the most Lars> correct type to use is string::size_type then. fixed Yes. This probably happens all over the code, in fact. Lars> Ok,... we go again... let me compile and commit first. OK. Do you want more of these, or have you had enough for today? JMarc
Re: NoGUI LyX
Angus Leeming <[EMAIL PROTECTED]> writes: | Attached is a patch that cleans up the code in InsetBibtex and InsetInclude | as outlined earlier. | | Incidentally, why does the return below (insetinclude.C) return | ost.str().c_str() rather than ost.str()? Look for te same constuct other places in the code and read te comments also tink about wat happens if the stringstream uses std::string and the rest of lyx use lyxstring Lgb
Re: more cxx warnings for buffer.C
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Here is what I get with latest cvs on buffer.C. Lars, if some warnings
| are bogus, I can shut them off for later testing on other files (I
| already did that for some warnings). I can also make a log for a whole
| compile session, if you feel bored :)
|
| JMarc
|
| cxx: Info: ../../lyx-devel/src/lyxparagraph.h, line 228:
| conversion to integral type of smaller size could lose data
| (D:intconlosbit)
| size_type size() const { return text.size(); }
| ^
This is know. Reason is knows and fix in known will perhaps happen in
1.2.0.
| cxx: Info: ../../lyx-devel/src/bufferlist.h, line 60: conversion to integral
| type of smaller size could lose data (D:intconlosbit)
| int size() const { return container.size(); }
| --^
This can safely change...fixed.
| cxx: Info: ../sigc++/slot.h, line 204: destructor for base class
| "SigC::Handle" is not virtual
| (D:basclsnondto)
| class LIBSIGC_API Connection:protected Handle
| ---^
The fix is probably what I posted in last mail.
| cxx: Info: ../sigc++/slot.h, line 312: destructor for base class
| "SigC::Handle" is not virtual
| (D:basclsnondto)
|:public Handle
| ---^
same
| cxx: Info: ../sigc++/basic_signal.h, line 139: destructor for base
| class "SigC::Signal_" is not virtual (D:basclsnondto)
| detected during instantiation of class "SigC::Signal0
| [with Marsh=SigC::Marshal]" at line 76 of
| "../../lyx-devel/src/insets/inseterror.h"
| :public Signal_
| --^
fix line 53 in basic_signal.h to read:
virtual ~Signal_();
Someone should send these fixes to the sigc++ team.
| cxx: Info: ../../lyx-devel/src/Literate.h, line 23: destructor for base
| class "LaTeX" is not virtual (D:basclsnondto)
| class Literate : public LaTeX {
| ^
Easy to fix, but I really disagree that Literate sould be a subclass
of LaTeX... fixed.
| cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
| "SigC::Handle" is not virtual
| (D:basclsnondto)
| detected during:
| instantiation of class "SigC::Slot1 [with P1=const
| std::vector> &]"
| at line 284 of "../sigc++/basic_signal.h"
| instantiation of class "SigC::Signal1 [with
| P1=const std::vector> &,
| Marsh=SigC::Marshal]" at line 79 of
| "../../lyx-devel/src/frontends/Dialogs.h"
|:public Handle
| ---^
again the same one.
| cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
| class "SigC::Signal_" is not virtual (D:basclsnondto)
| detected during instantiation of class "SigC::Signal1 [with P1=const std::vector> &, Marsh=SigC::Marshal]"
| at line 79 of "../../lyx-devel/src/frontends/Dialogs.h"
| :public Signal_
| --^
ditto as two up.
| cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
| "SigC::Handle" is not virtual
| (D:basclsnondto)
| detected during:
| instantiation of class
| "SigC::Slot1 [with P1=InsetBibKey *]" at line
| 284 of "../sigc++/basic_signal.h"
| instantiation of class "SigC::Signal1 [with
| P1=InsetBibKey *, Marsh=SigC::Marshal]" at line 81
| of "../../lyx-devel/src/frontends/Dialogs.h"
|:public Handle
| ---^
re
| cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
| class "SigC::Signal_" is not virtual (D:basclsnondto)
| detected during instantiation of class "SigC::Signal1 [with P1=InsetBibKey *, Marsh=SigC::Marshal]"
| at line 81 of "../../lyx-devel/src/frontends/Dialogs.h"
| :public Signal_
| --^
re
| cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
| "SigC::Handle" is not virtual
| (D:basclsnondto)
| detected during:
| instantiation of class
| "SigC::Slot1 [with P1=InsetBibtex *]" at line
| 284 of "../sigc++/basic_signal.h"
| instantiation of class "SigC::Signal1 [with
| P1=InsetBibtex *, Marsh=SigC::Marshal]" at line 83
| of "../../lyx-devel/src/frontends/Dialogs.h"
|:public Handle
| ---^
re
| cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
| class "SigC::Signal_" is not virtual (D:basclsnondto)
| detected during instantiation of class "SigC::Signal1 [with P1=InsetBibtex *, Marsh=SigC::Marshal]"
| at line 83 of "../../lyx-devel/src/frontends/
Re: NoGUI LyX
Attached is a patch that cleans up the code in InsetBibtex and InsetInclude
as outlined earlier.
Incidentally, why does the return below (insetinclude.C) return
ost.str().c_str() rather than ost.str()?
Angus
static inline
string unique_id() {
static unsigned int seed = 1000;
std::ostringstream ost;
ost << "file" << ++seed;
// Needed if we use lyxstring.
return ost.str().c_str();
}
On Wed, 27 Sep 2000, Angus Leeming wrote:
> Further investigation:
>
> InsetBibtex
>
> In InsetBibtex::Latex(Buffer const *, ostream & os,
> bool /*fragile*/, bool/*fs*/) const
> use the buffer that is passed but not used.
>
> InsetBibtex::getKeys() is called only from Buffer. Call it as getKeys(this)
>
> No need, therefore to store Buffer * owner in InsetBibtex or to use
> current_view.
>
> InsetInclude
> =
> A quick glance shows that Buffer * master can be replaced in each of the
> Latex(), DocBook(), Linuxdoc() methods.
patch27Sep2000.bz2
Re: Automatic dialogs
john jabbed, > On Tue, 26 Sep 2000, Dekel Tsur wrote: > I'm sceptical it would be simple to do this in a way that would suit all > the frontends. Remember Kaptain is for a specific GUI toolkit. > And as Lars points out they shouldn't be the same design anyway - the > environments have different ways of doing things anyway How about a two stage setup? the base mydialoginfo, with a the general information, but also an optional mydialoginfo.kde, etc., which could have additional information if needed? hawk --
Re: Gnome Toolbar: which interface to use?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> p.s. have you looked at my -ansi squashing patch yet I am going to do it. JMarc
Re: Gnome Toolbar: which interface to use?
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> Toolbars are good for displaying states (layout & mode for Marko> example) and for rarely used functions. However, since it is Marko> possible to build up toolbars similar to menus by using Marko> multiple toolbars and drop-down lists, it will be not wise to Marko> limit users with one toolbar. Wouldn't that be logical to use Marko> the same syntax in lib/ui/default.ui file for menus and Marko> toolbars? I am not sure whether menus and toolbars should be exactly the same thing, but the two classes should at least be closer one to the other... Feel free to investigate what kind of change should be done. Maybe the backends could be merged into one (although there is no text associated to an action in a toolbar, and no shortcut). In general, ideas on the interface to menus/toolbars are welcome. Tey still need further design work. Marko> BTW, is it possible to have Layouts (xforms toolbar) in menu? Since layout lists seems to be very long and xforms menu do not like being taller than the screen, this would not make much sense... Unless we change the layout files to allow classification of layouts in categories, which would fit nicely in a menu with submenus. JMarc
Re: Gnome Toolbar: which interface to use?
On 27 Sep 2000, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > Hmm, perhaps I should repost my design doc? > > Lgb please I would like to read it. I agree that this approach is definitely best, I was misunderstanding JMarc. thanks john p.s. have you looked at my -ansi squashing patch yet -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
more cxx warnings for buffer.C
Here is what I get with latest cvs on buffer.C. Lars, if some warnings
are bogus, I can shut them off for later testing on other files (I
already did that for some warnings). I can also make a log for a whole
compile session, if you feel bored :)
JMarc
cxx: Info: ../../lyx-devel/src/lyxparagraph.h, line 228:
conversion to integral type of smaller size could lose data
(D:intconlosbit)
size_type size() const { return text.size(); }
^
cxx: Info: ../../lyx-devel/src/bufferlist.h, line 60: conversion to integral
type of smaller size could lose data (D:intconlosbit)
int size() const { return container.size(); }
--^
cxx: Info: ../sigc++/slot.h, line 204: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
class LIBSIGC_API Connection:protected Handle
---^
cxx: Info: ../sigc++/slot.h, line 312: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
:public Handle
---^
cxx: Info: ../sigc++/basic_signal.h, line 139: destructor for base
class "SigC::Signal_" is not virtual (D:basclsnondto)
detected during instantiation of class "SigC::Signal0
[with Marsh=SigC::Marshal]" at line 76 of
"../../lyx-devel/src/insets/inseterror.h"
:public Signal_
--^
cxx: Info: ../../lyx-devel/src/Literate.h, line 23: destructor for base
class "LaTeX" is not virtual (D:basclsnondto)
class Literate : public LaTeX {
^
cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
detected during:
instantiation of class "SigC::Slot1 [with P1=const
std::vector> &]"
at line 284 of "../sigc++/basic_signal.h"
instantiation of class "SigC::Signal1 [with
P1=const std::vector> &,
Marsh=SigC::Marshal]" at line 79 of
"../../lyx-devel/src/frontends/Dialogs.h"
:public Handle
---^
cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
class "SigC::Signal_" is not virtual (D:basclsnondto)
detected during instantiation of class "SigC::Signal1 [with P1=const std::vector> &, Marsh=SigC::Marshal]"
at line 79 of "../../lyx-devel/src/frontends/Dialogs.h"
:public Signal_
--^
cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
detected during:
instantiation of class
"SigC::Slot1 [with P1=InsetBibKey *]" at line
284 of "../sigc++/basic_signal.h"
instantiation of class "SigC::Signal1 [with
P1=InsetBibKey *, Marsh=SigC::Marshal]" at line 81
of "../../lyx-devel/src/frontends/Dialogs.h"
:public Handle
---^
cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
class "SigC::Signal_" is not virtual (D:basclsnondto)
detected during instantiation of class "SigC::Signal1 [with P1=InsetBibKey *, Marsh=SigC::Marshal]"
at line 81 of "../../lyx-devel/src/frontends/Dialogs.h"
:public Signal_
--^
cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
detected during:
instantiation of class
"SigC::Slot1 [with P1=InsetBibtex *]" at line
284 of "../sigc++/basic_signal.h"
instantiation of class "SigC::Signal1 [with
P1=InsetBibtex *, Marsh=SigC::Marshal]" at line 83
of "../../lyx-devel/src/frontends/Dialogs.h"
:public Handle
---^
cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
class "SigC::Signal_" is not virtual (D:basclsnondto)
detected during instantiation of class "SigC::Signal1 [with P1=InsetBibtex *, Marsh=SigC::Marshal]"
at line 83 of "../../lyx-devel/src/frontends/Dialogs.h"
:public Signal_
--^
cxx: Info: ../sigc++/slot.h, line 410: destructor for base class
"SigC::Handle" is not virtual
(D:basclsnondto)
detected during:
instantiation of class
"SigC::Slot1 [with P1=InsetCommand *]" at line
284 of "../sigc++/basic_signal.h"
instantiation of class "SigC::Signal1 [with
P1=InsetCommand *, Marsh=SigC::Marshal]" at line
87 of "../../lyx-devel/src/frontends/Dialogs.h"
:public Handle
---^
cxx: Info: ../sigc++/basic_signal.h, line 278: destructor for base
Re: Gnome Toolbar: which interface to use?
On 27 Sep 2000, Jean-Marc Lasgouttes wrote: > I am not sure I have been clear here. What I think is that a right > solution should be easier to obtain that a wrong one. Of course, this > does not mean much in itself. I think we should only propose _logical_ > styles in menu/toolbar, not physical ones. So we should setup a scheme > to define these logical styles, and add hooks to these styles in > toolbar. Typewriter should be a "code" character style, for example. > There has been a proposal for that posted by Lars some times ago. > > 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. > This makes eminent sense. Thanks for the clarification. > Finally, two points: > > - the character popup is not modal (at least in xforms) and can be > kept open. > true but it's still a pain, if you are doing more than two things with it. > - toolbar is not a good tool when you need something often, but > keybindings are better. We have keybindings for > typewriter/sans-serif. > this is imho orthogonal to what we are talking about. most people do not use keyboard shortcuts, as gui access is "good enough". thanks john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: compiler warning with DEC cxx
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Info: ../../lyx-devel/src/lyxparagraph.h, line 228: | conversion
| Lars> to integral type of smaller size could lose data | size_type
| Lars> size() const { return text.size(); }
|
| Lars> true but still bullocks. This will eventually get fixed when we
| Lars> don't allow negative values for pos in LyXParagraph anymore, for
| Lars> now it has to stays as is.
|
| I guess it is rather related to the fact that lyxparagraph.h has
| typedef int size_type;
| whereas text.size() is a long (and long != int on alpha). Should we
| use
| typedef TextContainer::size_type size_type;
| instead?
TextContainer::size_type is unsigned, we need it signed.
| Lars> | and also a bunch of | | cxx: Info:
| Lars> ../../lyx-devel/src/insets/insetbib.h, line 78: overloaded |
| Lars> virtual function "Inset::display" is only partially overridden
| Lars> in | class "InsetBibtex" | class InsetBibtex : public
| Lars> InsetCommand { | --^
|
| Lars> These are bogus as usually.
|
| I'll shut down this one.
|
| Lars> | Then these are probably interesting | | cxx: Info:
| Lars> ../../lyx-devel/src/buffer.C, line 1626: conversion to integral
| Lars> | type of smaller size could lose data | currlinelen +=
| Lars> s.length(); | ^
|
| Lars> Hmm, we can make linelen to be unsigned int to avoid this.
|
| No, rather the relevant size_type (see above).
Perhaps...
Lgb
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: NoGUI LyX
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> InsetInclude = A quick glance shows that Buffer * Angus> master can be replaced in each of the Latex(), DocBook(), Angus> Linuxdoc() methods. Angus> Are InsetInclude::getMasterFilename() and Angus> InsetInclude::Validate() really sticking points? Note that InsetInclude has bugs related to this getMasterFilename() stuff. Basically, nested input files do not work when using the temp directory. We need to sort out how we get the parent of an included file: currently, this is done in some place with InsetParent, and in other places with the master buffer. This code needs a major review and fix session (I have several bug reports in my mail folder which depend on this). JMarc
Re: Gnome Toolbar: which interface to use?
John Levon <[EMAIL PROTECTED]> writes: | this is a difficult one. at the very least I don't think this argument | applies to Family - I use Typewriter all the time. Yes, but you probably shouldn't. What you should be able to do is to mark your text f.ex. as "code" or "verbatim". and then in another dialog decide how the "code" or "verbatim" is supposed to look and what font to use. We will get this when the character styles is implemented... I have a "design document" somewere... | If we want to guide the user to using LyX properly, fair enough, we'll | make it default to not having combo boxes for Size and maybe others ... | | But Family, Shape, and Series all have useful stuff that I don't | think will mislead them ! Any use of family (or other font attributes) ar in 90% of the cases mislead and wrong. | I always feel very edgy when it is suggested we should make things | difficult for people - in the end the wilful user will misuse lyx anyway | (all the while wondering why it's so difficult), and someone who genuinely | needs such will just be annoyed by it. | | So I say, default to no Size combobox, but include at least Family and | shape somehow... No. Instead do this the right way. | would other people like to comment ? Hmm, perhaps I should repost my design doc? Lgb
Re: NoGUI LyX
Further investigation: InsetBibtex In InsetBibtex::Latex(Buffer const *, ostream & os, bool /*fragile*/, bool/*fs*/) const use the buffer that is passed but not used. InsetBibtex::getKeys() is called only from Buffer. Call it as getKeys(this) No need, therefore to store Buffer * owner in InsetBibtex or to use current_view. InsetInclude = A quick glance shows that Buffer * master can be replaced in each of the Latex(), DocBook(), Linuxdoc() methods. Are InsetInclude::getMasterFilename() and InsetInclude::Validate() really sticking points? Angus On Wed, 27 Sep 2000, Juergen Vigna wrote: > On 27-Sep-2000 Angus Leeming wrote: > > This is a fair point that is valid not only in this case, but in all > > those insets that store Buffer * buffer directly. Perhaps we should > > really think hard about how to get rid of this store in all these cases. > > Yes we should! > > > Incidentally, in the case of InsetQuote, we can find the language in > > other ways. Shall I do this (see other mail). It doesn't address André's > > question about whether it's necessary, but it'll work cleanly. > > I did it already and "yes" the language IS needed here! > > > For reference, the following insets are passed Buffer * in the > > constructor: > > > > figinset.h:23: InsetFig(int tmpx, int tmpy, Buffer *); > > [will vanish so no need to think about this on] > > > insetbib.h:81: InsetBibtex(InsetCommandParams const &, Buffer *); > > insetinclude.h:30: InsetInclude(InsetCommandParams const &, Buffer > > *); insetparent.h:30: InsetParent(InsetCommandParams const &, > > Buffer * owner = 0); > > insettabular.h:76:InsetTabular(Buffer *, int rows = 1, int columns = > > 1); insettabular.h:78:InsetTabular(InsetTabular const &, Buffer *); > > At least insettabular does need the stored buffer ONLY for the Clone() > function! This means that if we add a Buffer * to the Clone() functions > this is not needed anymore! Lars any thoughts? > > Jürgen > > -- > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ > > Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] > Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 > I-39100 Bozen Web: http://www.sad.it/~jug > > -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ > > gossip, n.: > Hearing something you like about someone you don't. > -- Earl Wilson
Re: Gnome Toolbar: which interface to use?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> I always feel very edgy when it is suggested we should make John> things difficult for people - in the end the wilful user will John> misuse lyx anyway (all the while wondering why it's so John> difficult), and someone who genuinely needs such will just be John> annoyed by it. I am not sure I have been clear here. What I think is that a right solution should be easier to obtain that a wrong one. Of course, this does not mean much in itself. I think we should only propose _logical_ styles in menu/toolbar, not physical ones. So we should setup a scheme to define these logical styles, and add hooks to these styles in toolbar. Typewriter should be a "code" character style, for example. There has been a proposal for that posted by Lars some times ago. 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. JMarc
Re: NoGUI LyX
> Angus> Incidentally, in the case of InsetQuote, we can find the > Angus> language in other ways. Shall I do this (see other mail). It > Angus> doesn't address André's question about whether it's necessary, > Angus> but it'll work cleanly. > > Yes, for the case of InsetQuote, your solution seems to be the right > one. Ok, so who is doing the patch? Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: Gnome Toolbar: which interface to use?
On 27 Sep 2000, Jean-Marc Lasgouttes wrote: > Please think twice before doimg this. Think about what we want to do > with LyX, and why LyX is not KWord. Why would people bother with > styles if they can just change the typeface to large bold, add a > number and pretend this is a section heading? This is exactly what > happens with msword: the style system is here, but most people do not > use it. > > While it would not be wise to prevent people to change character size, > when somebody does it so often that the Character popup is not good > enough, then there is an _other_ problem somewhere. > > JMarc > hmmm... this is a difficult one. at the very least I don't think this argument applies to Family - I use Typewriter all the time. If we want to guide the user to using LyX properly, fair enough, we'll make it default to not having combo boxes for Size and maybe others ... But Family, Shape, and Series all have useful stuff that I don't think will mislead them ! I always feel very edgy when it is suggested we should make things difficult for people - in the end the wilful user will misuse lyx anyway (all the while wondering why it's so difficult), and someone who genuinely needs such will just be annoyed by it. So I say, default to no Size combobox, but include at least Family and shape somehow... this is a very difficult set of decisions to make, as this is a crucial interface. I agree with you to a large degree though ! would other people like to comment ? thanks john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: NoGUI LyX
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Incidentally, in the case of InsetQuote, we can find the Angus> language in other ways. Shall I do this (see other mail). It Angus> doesn't address André's question about whether it's necessary, Angus> but it'll work cleanly. Yes, for the case of InsetQuote, your solution seems to be the right one. JMarc
Re: NoGUI LyX
On 27-Sep-2000 Angus Leeming wrote: > > This is a fair point that is valid not only in this case, but in all those > insets that store Buffer * buffer directly. Perhaps we should really think > hard about how to get rid of this store in all these cases. > Yes we should! > Incidentally, in the case of InsetQuote, we can find the language in other > ways. Shall I do this (see other mail). It doesn't address André's question > about whether it's necessary, but it'll work cleanly. I did it already and "yes" the language IS needed here! > > For reference, the following insets are passed Buffer * in the constructor: > > figinset.h:23: InsetFig(int tmpx, int tmpy, Buffer *); [will vanish so no need to think about this on] > insetbib.h:81: InsetBibtex(InsetCommandParams const &, Buffer *); > insetinclude.h:30: InsetInclude(InsetCommandParams const &, Buffer *); > insetparent.h:30: InsetParent(InsetCommandParams const &, Buffer * > owner = 0); > insettabular.h:76:InsetTabular(Buffer *, int rows = 1, int columns = 1); > insettabular.h:78:InsetTabular(InsetTabular const &, Buffer *); At least insettabular does need the stored buffer ONLY for the Clone() function! This means that if we add a Buffer * to the Clone() functions this is not needed anymore! Lars any thoughts? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ gossip, n.: Hearing something you like about someone you don't. -- Earl Wilson
Re: NoGUI LyX
On 27-Sep-2000 Angus Leeming wrote: [snip] > features.bufferParams().language [snip] > why not use the Buffer * that is passed but not used? Good spotted! I use this and now InsetQuotes does not have any current_view. (as soon as I commit ;) While the first one is not needed anymore as I removed the "default" language (well it will be removed with my next commit), I will leave it asis! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Television has proved that people will look at anything rather than each other. -- Ann Landers
Re: Gnome Toolbar: which interface to use?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> At least KDE toolbar will have drop-down combo boxes for John> selecting font size etc. John> even though the current Character dialog system is useful in John> some things, it can be a major pain in the butt ... Please think twice before doimg this. Think about what we want to do with LyX, and why LyX is not KWord. Why would people bother with styles if they can just change the typeface to large bold, add a number and pretend this is a section heading? This is exactly what happens with msword: the style system is here, but most people do not use it. While it would not be wise to prevent people to change character size, when somebody does it so often that the Character popup is not good enough, then there is an _other_ problem somewhere. JMarc
Re: NoGUI LyX
JMarc> And what happens when insets are copy/pasted to another document? This is a fair point that is valid not only in this case, but in all those insets that store Buffer * buffer directly. Perhaps we should really think hard about how to get rid of this store in all these cases. Incidentally, in the case of InsetQuote, we can find the language in other ways. Shall I do this (see other mail). It doesn't address André's question about whether it's necessary, but it'll work cleanly. Angus For reference, the following insets are passed Buffer * in the constructor: figinset.h:23: InsetFig(int tmpx, int tmpy, Buffer *); insetbib.h:81: InsetBibtex(InsetCommandParams const &, Buffer *); insetinclude.h:30: InsetInclude(InsetCommandParams const &, Buffer *); insetparent.h:30: InsetParent(InsetCommandParams const &, Buffer * owner = 0); insettabular.h:76:InsetTabular(Buffer *, int rows = 1, int columns = 1); insettabular.h:78:InsetTabular(InsetTabular const &, Buffer *);
RE: Gnome Toolbar: which interface to use?
On Wed, 27 Sep 2000, Juergen Vigna wrote: > > On 27-Sep-2000 Marko Vendelin wrote: > > > > As it has been discussed earlier, toolbar may use the same interface as > > menubar. The attached screenshot demonstrates sample implementation of > > toolbar displaying main-menu. Each submenu of menubar is presented by > > toolbar and each sub-submenu --- by drop-down list (in the screenshot > > Insert/Special character/Ellipsis is selected). > > I always have another view of a toolbar (some icons and maybe text), but > maybe we have another idea of what a toolbar is #:O) > > Jürgen > At least KDE toolbar will have drop-down combo boxes for selecting font size etc. even though the current Character dialog system is useful in some things, it can be a major pain in the butt ... john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: GUII status (was Re: patch InsetInfo->InsetNote)
On Wed, 27 Sep 2000, Allan Rae wrote: > Here's a really simple example: > > Preferences is in the xforms tree. Only half the lyxrc variables are in > the dialog. The dialog will be completely redesigned to limit the > possiblity of segfaults caused by tabs not fitting in the dialog width. > It's listed in the GUII page as "completed". > > Does that make sense to you? It looks like it should be called "In > Progress" or at least "In Codebase" to distinguish it from something which > has been completed and will only be fine-tuned in future. > > Then again a better explanation in guii.php3 of what you really mean by > the different states would also help. > > Allan. (ARRae) > Ok, you're right. The status thing was just a first stab at something, and it indeed does seem it's not adequate. So can you give a complete list of the states you think should exist and what they mean ? I ask you only because you have better idea of porting process than me thanks john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: Automatic dialogs
On Tue, 26 Sep 2000, Dekel Tsur wrote: > Designing a XForms dialog with fdesign was always a tedious task, > which is why there are new features with no GUI support (for example: > per-paragraph spacing). With the GUII, the situation is worse, as the GUI work > is needed to be repeated 3 times (or even more in the future). > > So, I want to suggest a new approach for doing GUII dialogs: > The dialogs structure and logiv will be defined by in a simple text file, > and the dialogs will be built in run-time from these files. > An example for this approach can be seen in Kaptain > (http://www.hszk.bme.hu/~tz124/kaptain/) which is a "universal graphical > front-end for command line programs". See > http://www.hszk.bme.hu/~tz124/kaptain/docs/enscript.html > for an example. > > In addition to easier maintenance, it will also add new abilities like the > ability to define new insets with text files, and the ability to load > various latex packages and set their parameters using a GUI dialog. > I'm sceptical it would be simple to do this in a way that would suit all the frontends. Remember Kaptain is for a specific GUI toolkit. And as Lars points out they shouldn't be the same design anyway - the environments have different ways of doing things anyway john -- "Ten decimals [digits of Pi] are sufficient to give the circumference of the earth to the fraction of an inch, and thirty decimals would give the circumference of the whole visible universe to a quantity imperceptible with the most powerful microscope." - Simon Newcomb
Re: NoGUI LyX
On 27-Sep-2000 Angus Leeming wrote: > Several of the insets already store Buffer * buffer directly, this being > passed to the inset through the constructor. If we do the same here and in > insetref.[Ch], then NONE of the insets use current_view at all. > > Shall I do this? Be aware that in general this is no good idea! You can have a Buffer parameter in the constructor if you need this for constructing the object, but NOT for saving it internally (I know we have this in insettabular, but this doesn't mean I like it!). One question, what do you do if you copy the inset to another buffer? Also I think that requesting the document-language is wrong in this context (or old behaviour) if you want to do something then the language should be the one the inset is drawn with, which CAN be the document wide language, BUT it can also be another language! So we would need a method which tells us in what font the current inset is drawn! I will have a look at this as I need it for setting the right language in an insettext when creating it, but if you are faster and present a working solution I would be happy! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Why is the alphabet in that order? Is it because of that song? -- Steven Wright
Re: NoGUI LyX
Further investigation reveals alternative routes of finding the language: In InsetQuotes::Validate(LaTeXFeatures & features) use features.bufferParams().language in place of current_view->buffer()->GetLanguage() int InsetQuotes::Latex(Buffer const *, ostream & os, bool /*fragile*/, bool) const why not use the Buffer * that is passed but not used? Angus On Wed, 27 Sep 2000, Angus Leeming wrote: > Several of the insets already store Buffer * buffer directly, this being > passed to the inset through the constructor. If we do the same here and in > insetref.[Ch], then NONE of the insets use current_view at all. > > Shall I do this? > > Angus > > On Wed, 27 Sep 2000, Andre Poenitz wrote: > > The _only_ _two_ obstacles for batch export to any format without popping > > up the GUI are around line 297 and line 236 in insets/insetquotes.C the > > use of current_view to get the buffer's language > > current_view->buffer()->GetLanguage(). > > > > If this is replaced by "default", it works! > > > > Of course, "default" might not the right thing to use, so if anybody > > could help me to find the language of the inset without using > > "current_view", I'd be glad to prepare a patch that would add a feature I > > have been missing for years... > > > > Andre' > > > > PS: Maybe someone more knowledgable could check whether the explicit use > > of the buffer's language in these two places makes sense at all.
Re: NoGUI LyX
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Several of the insets already store Buffer * buffer directly, Angus> this being passed to the inset through the constructor. If we Angus> do the same here and in insetref.[Ch], then NONE of the insets Angus> use current_view at all. And what happens when insets are copy/pasted to another document? JMarc
Re: NoGUI LyX
> Several of the insets already store Buffer * buffer directly, this being > passed to the inset through the constructor. If we do the same here and in > insetref.[Ch], then NONE of the insets use current_view at all. > > Shall I do this? I live under the impression that current_view is a Bad Thing, so it'd be certainly fine with me... Andre' PS: This remains: : Maybe someone more knowledgable could check whether the explicit use of : the buffer's language in these two places makes sense at all. -- Andre' Poenitz [EMAIL PROTECTED]
Re: NoGUI LyX
Several of the insets already store Buffer * buffer directly, this being passed to the inset through the constructor. If we do the same here and in insetref.[Ch], then NONE of the insets use current_view at all. Shall I do this? Angus On Wed, 27 Sep 2000, Andre Poenitz wrote: > The _only_ _two_ obstacles for batch export to any format without popping > up the GUI are around line 297 and line 236 in insets/insetquotes.C the use > of current_view to get the buffer's language > current_view->buffer()->GetLanguage(). > > If this is replaced by "default", it works! > > Of course, "default" might not the right thing to use, so if anybody could > help me to find the language of the inset without using "current_view", I'd > be glad to prepare a patch that would add a feature I have been missing for > years... > > Andre' > > PS: Maybe someone more knowledgable could check whether the explicit use of > the buffer's language in these two places makes sense at all.
NoGUI LyX
The _only_ _two_ obstacles for batch export to any format without popping up the GUI are around line 297 and line 236 in insets/insetquotes.C the use of current_view to get the buffer's language current_view->buffer()->GetLanguage(). If this is replaced by "default", it works! Of course, "default" might not the right thing to use, so if anybody could help me to find the language of the inset without using "current_view", I'd be glad to prepare a patch that would add a feature I have been missing for years... Andre' PS: Maybe someone more knowledgable could check whether the explicit use of the buffer's language in these two places makes sense at all. -- Andre' Poenitz [EMAIL PROTECTED]
Re: compiler warning with DEC cxx
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Info: ../../lyx-devel/src/lyxparagraph.h, line 228: | conversion
Lars> to integral type of smaller size could lose data | size_type
Lars> size() const { return text.size(); }
Lars> true but still bullocks. This will eventually get fixed when we
Lars> don't allow negative values for pos in LyXParagraph anymore, for
Lars> now it has to stays as is.
I guess it is rather related to the fact that lyxparagraph.h has
typedef int size_type;
whereas text.size() is a long (and long != int on alpha). Should we
use
typedef TextContainer::size_type size_type;
instead?
Lars> | and also a bunch of | | cxx: Info:
Lars> ../../lyx-devel/src/insets/insetbib.h, line 78: overloaded |
Lars> virtual function "Inset::display" is only partially overridden
Lars> in | class "InsetBibtex" | class InsetBibtex : public
Lars> InsetCommand { | --^
Lars> These are bogus as usually.
I'll shut down this one.
Lars> | Then these are probably interesting | | cxx: Info:
Lars> ../../lyx-devel/src/buffer.C, line 1626: conversion to integral
Lars> | type of smaller size could lose data | currlinelen +=
Lars> s.length(); | ^
Lars> Hmm, we can make linelen to be unsigned int to avoid this.
No, rather the relevant size_type (see above).
Lars> | cxx: Info: ../../lyx-devel/src/buffer.C, line 1475: variable |
Lars> "actcell" was set but never used | int actcell = 0; |
Lars> ^
Lars> This was a nice one. Other compiler would probably this one
Lars> since actcell is also present in line 1576. I removed it.
I have a bunch of similar ones, it seems (I only showed example of
typical messages).
Lars> Let me commit, and you can make a new list.
OK.
JMarc
Re: compiler warning with DEC cxx
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
|
| Angus> Perhaps the following will be useful to someone? Angus
|
| It seems Juergen forgot to add his linelen argument in many places...
| Juergen, could you have a look?
|
| I also have:
|
| cxx: Warning: ../../../lyx-devel/src/insets/insettext.C, line 1034: missing
| return statement at end of non-void function "InsetText::Ascii"
| }
| ^
|
| I was concerned that I did not have the same warnings as Angus, so I
| looked up the man page (I use cxx 6.2) and found a seeminly
| interesting option -w0. When Using it, I get tons of warnings for
| buffer.C. Here are a few of them, I'd be interested to have some
| opinion.
|
| cxx: Info: ../../lyx-devel/src/lyxparagraph.h, line 228:
| conversion to integral type of smaller size could lose data
| size_type size() const { return text.size(); }
true but still bullocks.
This will eventually get fixed when we don't allow negative values for
pos in LyXParagraph anymore, for now it has to stays as is.
| ^
| cxx: Info: ../../lyx-devel/src/Bullet.h, line 153: conversion to integral
| type of smaller size could lose data
| character = c;
| --^
We could perhaps make this:
character = char(c);
I guess te warning goes away then?
Hm, after having a second look: just change font, character and size
to ints instead of shorts. (I did that)
| cxx: Info: ../sigc++/slot.h, line 204: destructor for base class
| "SigC::Handle" is not virtual
| class LIBSIGC_API Connection:protected Handle
| ---^
| cxx: Info: ../sigc++/slot.h, line 312: destructor for base class
| "SigC::Handle" is not virtual
|:public Handle
| ---^
These should probably be fixed.
Sems like a :
virtual ~Handle() {}
in handle.h would do the trick.
| and also a bunch of
|
| cxx: Info: ../../lyx-devel/src/insets/insetbib.h, line 78: overloaded
| virtual function "Inset::display" is only partially overridden in
| class "InsetBibtex"
| class InsetBibtex : public InsetCommand {
| --^
These are bogus as usually.
| Then these are probably interesting
|
| cxx: Info: ../../lyx-devel/src/buffer.C, line 1626: conversion to integral
| type of smaller size could lose data
| currlinelen += s.length();
| ^
Hmm, we can make linelen to be unsigned int to avoid this.
| cxx: Info: ../../lyx-devel/src/buffer.C, line 1475: variable
| "actcell" was set but never used
| int actcell = 0;
| ^
This was a nice one. Other compiler would probably this one since
actcell is also present in line 1576.
I removed it.
| cxx: Info: ../../lyx-devel/src/buffer.C, line 1479: variable
| "fname1" was declared but never referenced
| string fname1 = TmpFileName();
| ---^
I removed this too.
|
| As you might imagine, the quantity of information for a whole compile
| would be overwhelming. However, I feel we should try to cleanup some
| of these. So, what are the ones which are relevant?
Let me commit, and you can make a new list.
Lgb
LyX without GUI
I just noticed that batch export to _Text_ is already possible without Gui
and Xvfb black magic. The patch is not nice but really tiny so I'd
propose inclusion in the CVS tree.
--- snip -
Index: lyx_main.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
retrieving revision 1.50
diff -u -r1.50 lyx_main.C
--- lyx_main.C 2000/09/26 13:54:53 1.50
+++ lyx_main.C 2000/09/27 11:09:55
@@ -740,6 +740,8 @@
else if (arg == "-e" || arg == "--export") {
if (i + 1 < *argc) {
string type(argv[i+1]);
+ if (type == "txt")
+ gui = false;
removeargs = 2;
batch_command = "buffer-export " + type;
} else
--- snip -
Note that using \use_gui from lyxrc does not help since the Gui is already
initialized before lyxrc is read.
Andre'
PS: I am pretty sure this was not possible a while ago, so I guess the
clean up resulting from the work on the Exporter and maybe on GUII did
help here. Good work, Guys!
The more important batch export to LaTeX still does not work but from a
first glance after months I'd say we progress without explicitly working
on it ;-)
--
Andre' Poenitz [EMAIL PROTECTED]
Re: compiler warning with DEC cxx
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Perhaps the following will be useful to someone? Angus
It seems Juergen forgot to add his linelen argument in many places...
Juergen, could you have a look?
I also have:
cxx: Warning: ../../../lyx-devel/src/insets/insettext.C, line 1034: missing
return statement at end of non-void function "InsetText::Ascii"
}
^
I was concerned that I did not have the same warnings as Angus, so I
looked up the man page (I use cxx 6.2) and found a seeminly
interesting option -w0. When Using it, I get tons of warnings for
buffer.C. Here are a few of them, I'd be interested to have some
opinion.
cxx: Info: ../../lyx-devel/src/lyxparagraph.h, line 228:
conversion to integral type of smaller size could lose data
size_type size() const { return text.size(); }
^
cxx: Info: ../../lyx-devel/src/Bullet.h, line 153: conversion to integral
type of smaller size could lose data
character = c;
--^
cxx: Info: ../../lyx-devel/src/Bullet.h, line 168: conversion to integral
type of smaller size could lose data
font = f;
-^
and then a few like this one:
cxx: Info: ../sigc++/slot.h, line 204: destructor for base class
"SigC::Handle" is not virtual
class LIBSIGC_API Connection:protected Handle
---^
cxx: Info: ../sigc++/slot.h, line 312: destructor for base class
"SigC::Handle" is not virtual
:public Handle
---^
and also a bunch of
cxx: Info: ../../lyx-devel/src/insets/insetbib.h, line 78: overloaded
virtual function "Inset::display" is only partially overridden in
class "InsetBibtex"
class InsetBibtex : public InsetCommand {
--^
Then these are probably interesting
cxx: Info: ../../lyx-devel/src/buffer.C, line 1626: conversion to integral
type of smaller size could lose data
currlinelen += s.length();
^
cxx: Info: ../../lyx-devel/src/buffer.C, line 1475: variable
"actcell" was set but never used
int actcell = 0;
^
cxx: Info: ../../lyx-devel/src/buffer.C, line 1479: variable
"fname1" was declared but never referenced
string fname1 = TmpFileName();
---^
As you might imagine, the quantity of information for a whole compile
would be overwhelming. However, I feel we should try to cleanup some
of these. So, what are the ones which are relevant?
JMarc
Re: compiler warning with DEC cxx
Angus Leeming <[EMAIL PROTECTED]> writes: | _repository -O2 -MD -c buffer.C | cxx: Warning: insets/insetlabel.h, line 41: | "int InsetLabel::Ascii(const Buffer *, std::ostream &) const" does | not match "Inset::Ascii" -- virtual function override intended? | int Ascii(Buffer const *, std::ostream &) const; thanks, should be fixed now Lgb
RE: compiler warning with DEC cxx
On 27-Sep-2000 Angus Leeming wrote: > Perhaps the following will be useful to someone? > Angus > > > cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. Thanks fixed now! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ For God's sake, stop researching for a while and begin to think!
compiler warning with DEC cxx
Perhaps the following will be useful to someone? Angus cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../src/c headers -I/usr/local/include -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx _repository -O2 -MD -c buffer.C cxx: Warning: insets/insetlabel.h, line 41: "int InsetLabel::Ascii(const Buffer *, std::ostream &) const" does not match "Inset::Ascii" -- virtual function override intended? int Ascii(Buffer const *, std::ostream &) const; ^ cxx: Warning: insets/insetlabel.h, line 41: "int InsetLabel::Ascii(const Buffer *, std::ostream &) const" does not match "InsetCommand::Ascii" -- virtual function override intended? int Ascii(Buffer const *, std::ostream &) const; ^ cxx: Warning: insets/insetref.h, line 44: "int InsetRef::Ascii(const Buffer *, std::ostream &) const" does not match "Inset::Ascii" -- virtual function override intended? int Ascii(Buffer const *, std::ostream &) const; ^ cxx: Warning: insets/insetref.h, line 44: "int InsetRef::Ascii(const Buffer *, std::ostream &) const" does not match "InsetCommand::Ascii" -- virtual function override intended? int Ascii(Buffer const *, std::ostream &) const; ^ cxx: Warning: insets/inseturl.h, line 47: "int InsetUrl::Ascii(const Buffer *, std::ostream &) const" does not match "Inset::Ascii" -- virtual function override intended? int Ascii(Buffer const *, std::ostream &) const; ^ cxx: Warning: insets/inseturl.h, line 47: "int InsetUrl::Ascii(const Buffer *, std::ostream &) const" does not match "InsetCommand::Ascii" -- virtual function override intended?
Re: cleanup patch and Re: patch InsetInfo->InsetNote
This is a reply to several different mails...
Allan> Committed. I had to fix a couple of small things (noncopyable wasn't
Allan> removed in a couple of places and gave warnings for examlpe).
Interesting. The value of testing on different compilers, I guess.
Allan> I'd prefer it if you removed the uSignal_ and hSignal_ pointers and
Allan> just had a BufferDependency variable to switch which connections
Allan> are made show(). Keeps the same interface but removes what
Allan> really are unnecessary pointer variables.
Sure. Good idea. As I said before, this should be regarded as
work-in-progress. I worked out how to implement a clean interface to FormBase
thanks largely to the discussions on this list. Cleaning up the internals is
the same; it just takes a good idea!
Allan> Why do you want to change the for loop in forms/makefile into one line?
Allan> It's a heck of a lot easier to read when formatted the way it was.
Allan> I left this with the original formatting.
Whatever. I was having problems with sh on the DEC. Hardly mission-critical!
Allan> You've thrown a googly to me with those new changes in your
Allan> latest patch. The arguement below still holds as I still think we
Allan> need to allow derived classes to handle extra signals. Table
Allan> uses extra signals for instance. It's certainly an interesting
Allan> twist you've taken with the BufferDependency idea.
Just trying to keep you on your toes! Although some classes have extra
signals, ALL of them have the hideXXX/updateBufferDependent signals and
therefore it's THESE and ONLY THESE that could go in the base class. As
you've committed this stuff, I guess that you've convinced yourself that it's
actually a pretty neat and tidy idea.
Lars> I'd rather see the iostream way applied here:
Lars>
Lars> class Base {
Lars> public:
Lars> pubShow() { show(); }
Lars> protected:
Lars> virtual show() { connect(); }
Lars> virtual connect() = 0;
Lars> };
Lars>
Lars> public interface is non-virtual all virtual methods are protected.
Lars, I'm not sure whether you're talking about Allan's hypothetical way of
doing things or the one I actually submitted and which has, apparently, been
committed. In MY stuff, all the virtual stuff IS protected, although I had no
idea that this was "good practice". Still living and learning.
Angus
RE: babel.sty, english.ldf
On 26-Sep-2000 Garst R. Reese wrote: > entries for canadien (french, note the e), and acadian, another french Do you like me to insert also acadian as "French Candian"? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dealing with the problem of pure staff accumulation, all our researches ... point to an average increase of 5.75% per year. -- C.N. Parkinson
Re: language.C
On 27-Sep-2000 Kevin Atkinson wrote: > > In the CVS version I noticed that British was just "en" instead of > "en_GB". Is there a reason for this? Garst patch has it as "en_GB" like > it should. Fixed! (commit soon) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ In the dimestores and bus stations People talk of situations Read books repeat quotations Draw conclusions on the wall. -- Bob Dylan
RE: Gnome Toolbar: which interface to use?
On Wed, 27 Sep 2000, Juergen Vigna wrote: > On 27-Sep-2000 Marko Vendelin wrote: > > > > As it has been discussed earlier, toolbar may use the same interface as > > menubar. The attached screenshot demonstrates sample implementation of > > toolbar displaying main-menu. Each submenu of menubar is presented by > > toolbar and each sub-submenu --- by drop-down list (in the screenshot > > Insert/Special character/Ellipsis is selected). > > I always have another view of a toolbar (some icons and maybe text), but > maybe we have another idea of what a toolbar is #:O) Obviously, I haven't put too much effort into it yet. So, icons are just missing in this implementation :). Actually, menuitems may have icons too in gnome and kde. Marko
RE: Gnome Toolbar: which interface to use?
On 27-Sep-2000 Marko Vendelin wrote: > > As it has been discussed earlier, toolbar may use the same interface as > menubar. The attached screenshot demonstrates sample implementation of > toolbar displaying main-menu. Each submenu of menubar is presented by > toolbar and each sub-submenu --- by drop-down list (in the screenshot > Insert/Special character/Ellipsis is selected). I always have another view of a toolbar (some icons and maybe text), but maybe we have another idea of what a toolbar is #:O) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Nothing so needs reforming as other people's habits. -- Mark Twain
Gnome Toolbar: which interface to use?
As it has been discussed earlier, toolbar may use the same interface as menubar. The attached screenshot demonstrates sample implementation of toolbar displaying main-menu. Each submenu of menubar is presented by toolbar and each sub-submenu --- by drop-down list (in the screenshot Insert/Special character/Ellipsis is selected). Before implementing the toolbar for Gnome frontend, it will be nice to know which interface (Menubar_pimpl or Toolbar_pimpl) will be used by LyX in future versions (1.2.0)? If we plan to switch toolbar interface to Menubar_pimpl then there is no need for Toolbar_pimpl-alike gnome frontend toolbar. Marko gtoolbar.png
Re: patch InsetInfo->InsetNote
Allan Rae <[EMAIL PROTECTED]> writes:
| On Wed, 27 Sep 2000, Allan Rae wrote:
|
| > On Tue, 26 Sep 2000, Angus Leeming wrote:
| > [...]
| > > Angus> Finally, I have made the xforms implementation of FormCopyright a
| > > Angus> derived class of FormBase and demonstrated that none of these
| > > Angus> FormXXX classes need be dependent on Dialogs.h if they are
| > > Angus> passed pointers to the relevant show, hide and update signals
| > > Angus> directly by Dialogs.C.
| > >
| > > Allan> I don't like the looks of this much at all...
| > >
| > > All fair comment. I was, however, merely trying to demonstrate that it's
| > > possible to have one base class that does all this rather nasty stuff. I was
| >
| > But one base class shouldn't be trying to second guess what it's derived
| > classes are going to be doing.
| >
| > > thinking last night that the production code would merely need a flag
| > > definining whether the browser was invariant across all buffers and therefore
| > > needed a hideAll signal, or was buffer dependent and therefore required the
| > > hideBufferDependent, updateBufferDependent signals.
| >
| > Just add these lines to FormBase:
| >
| > /// Derived classes setup signal connections
| > virtual void connect() = 0;
| > /// Derived classes disconnect signal connections
| > virtual void disconnect() = 0;
| >
| > That way all connections are handled by the derived classes. You could
| > alternatively define empty functions so that derived classes that don't
| > need extra connections aren't required to implement them but that's more a
| > matter of style since no-one is going to create an instance of a FormBase.
|
| D'oh! that's not going to work as simply as that!
Why not?
class Base {
show() { connect(); }
virtual connect() = 0;
};
class Derived {
virtual connect() { showIt(); }
};
Derived derived;
derived.show();
should work as expected.
Or peraps that I just don't understand what you are talking about.
| show() and hide() should call the derived types connect amd diconnect
| methods and for this to work there has to be a pointer/reference to the
| derived class passed to the FormBase constructor so we can call
| derived_->connect().
Why?
| Then again a given dialog could just redefine
| show() and hide() and avoid all this stuff (or could it?)
No, I don't think so.
I'd rather see the iostream way applied here:
class Base {
public:
pubShow() { show(); }
protected:
virtual show() { connect(); }
virtual connect() = 0;
};
public interface is non-virtual all virtual methods are protected.
Lgb
Re: cleanup patch
On Wed, 27 Sep 2000, Allan Rae wrote: > On Wed, 27 Sep 2000, Allan Rae wrote: > > > On Tue, 26 Sep 2000, Angus Leeming wrote: > > > This has meant that the name of the callback function in several .fd files > > > has changed. If YOU apply this patch, please "make updatesrc" in > > > src/frontends/xforms/forms. > > > > Okay, I think I'll apply this to my tree and get the compiler running to > > test it. > > Committed. I had to fix a couple of small things (noncopyable wasn't > removed in a couple of places and gave warnings for examlpe). I'd prefer it if you removed the uSignal_ and hSignal_ pointers and just had a BufferDependency variable to switch which connections are made in show(). Keeps the same interface but removes what really are unnecessary pointer variables. Allan. (ARRae)
