Re: [patch]: adding transformations to InsetExternal
On Sat, 4 Oct 2003, Angus Leeming wrote: > Oh come on! We have two or three Templates that are going to be used > by many people. The rest are really just curiosities. That's because the system is too complex for others to contribute templates. I see lots of relevant template being added. Suitable for general use: - Spread-sheets - Financial applications - All kinds of graphers - Calendars - Other words processors - HTML editors and then there are a wide range of esoterics: - GUI builders - Music typesetting - Astronomy applications - Chemical drawing programs - CD cover programs - 3D modellers - and whatever niche you are in where you use a computer to make some kind of graphics. You can even use wine to embed the output from Windows applications in your documents. Most of these can make good use of at least the scaling transformation, but rotation and cropping transformation are always useful. So, maybe the best feature to develop is a "Template" editing GUI in the form of a "Wizard" which helps you make one. Best regards, Asger
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Mon, Oct 06, 2003 at 05:26:11PM +0200, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> Jean-Marc, Lars: > > Andre> Can I please have your confirmation that 'we' decided to remove > Andre> inactive items from the menu instead of graying them out? > > Andre> I find this horribly bad UI. A user never gets to know the > Andre> 'thing is there' unless he happens to check the menus at the > Andre> right time. > > > I see the issue is getting out of hands :) > > My take on inactive items: > > * some of them are suppressed because the frontend does not implement > them (thesaurus, toggle tooltips in qt, for example). I guess it is > OK with you Yes. > * some of them are suppressed because LyX is not configured to use > them (File>Fax, Tools>Check TeX). This makes sense to me since this > always greyed out items are not informative (remember that the menus > are already overcrowded) Well, they make the user think about what needs to be done to gain access to these features. More likely than an entry in the UserGuide anyway. But I can live with that. > * some of them would be too annoying (for example people not using > literate programming would wonder forever what this greyed out > Tools>Build Program can be) Same here. > * in some cases, it really simplifies the UI IMO, like the > File>Version Control submenu. It's certainly ok if a whole unaccessible menu hides behind a single greyed out entry. That's enough of a hint. > * the contextual 'settings' entry in Edit are very useful, since we do > not want to have lots of inactive entries (one for each inset type? > great...). This is functionality we did not have before. > > * so finally, we come to the one that irritates you, your beloved math > submenu. Tables as well. > I have too say that I am not really in love with this menu, > but I won't criticize it too hard, since I have nothing better to > propose for now. I think that the fact that it appears and disappears > contextually is not too bad if we make sure that the edit menu is > always kept short enough so that people can spot such entries easily > (and of course, this is a pretty good reason for moving Preference to > Tools). I don't agree here. Table and math are even more integrated with LyX than the spellchecker, yet the the spellchecker gets greyed out but math and tables get removed. > Therefore, there plenty of valuable uses of this optional stuff, and > blanket statements like the title of your bug are indeed a bit > silly... So what remains are the problems of the dreaded math and > table menus. A good solution to this might be to do heavy surgery on > them: you just decided to include there each feature that may be > useful one day (like for example the math_extern menu, which is more a > toy than anything else, and is probably more bewildering for a user > than moving prefs to another menu...). I am fine with removing math-extern from the menus, even if I put it there on an explicit user request (don't remember when, though). I furthermore don't think 'weird stuff' in the third menu level of Edit->math needs to make sense for people not using math at all. But removing math is not ok. Andre'
Re: std::string pathc
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Tue, Oct 07, 2003 at 06:32:29AM +0200, Lars Gullik Bjønnes spake thusly: >> To: Martin Vermeer <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED] >> Subject: Re: std::string pathc >> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes) >> Organization: LyX Developer http://www.lyx.org/ >> Date: Tue, 07 Oct 2003 06:32:29 +0200 >> In-Reply-To: <[EMAIL PROTECTED]> >> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) >> X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi) >> >> Martin Vermeer <[EMAIL PROTECTED]> writes: >> >> | rest of the evening... here's the patch needed for STLport. Feel free >> | to commit, I'm hitting the sack. >> >> Do you really need in all those places? You seem to add it in >> more places than I removed "support/std_string.h" > | The message is the following: > | In file included from math_macrotable.C:13: | math_macrotable.h:26: `string' undeclared in namespace `_STL' Yes... but this is math_macrotable.h only. Did you fix all the problems in one go, or did you try to recompile in between. My method was to begin a recombile everytime i added a > >> But it shouldn't really matter... strange though that STLport does not >> forward declare std::string in about the same places as libstdc++. > | What does the standard say? Brokken includes in all his | examples. The standard say nothing about this. -- Lgb
Re: The recent xpm changes
Juergen Spitzmueller wrote:
> John Levon wrote:
>> Appear to have broken Document->Settings->Bullets for Qt (RH9 at
>> least). The background is black.
>
> I am seeing this for at least two weeks now.
> Jürgen.
Thanks for the early feedback then ;-)
They all look fine to me from within LyX. RH8.
Actually guys, this is quite interesting. They all look fine when
viewed with kview but appear as you describe when viewed with
kuickshow
$ kuickshow lib/images/standard.xpm lib/images/amssymb.xpm
lib/images/psnfss[1-4].xpm
A my bad indeed, for standard.xpm at least
$ cvs -q diff -r 1.3 lib/images/standard.xpm
-static char const * standard[] = {
+static char const * s#d2b48cdard[] = {
Interstingly, reverting that change doesn't affect the appearance in
kuickshow --- it still has a black background.
The previous change --- on 1 Dec 1999 --- was
-"n c #b8bcb8",
+"n c None",
So I claim that this weird appearence isn't my fault.
It seems that there are two files with messed-up names. I've fixed
both of those.
$ find lib -name "*.xpm" | xargs grep 'static *char' | less
lib/images/redo.xpm:static char * #ffo_xpm[] = {
lib/images/standard.xpm:static char const * s#d2b48cdard[] = {
I guess that the heart of this matter is to ascertain why the files
appear fine when viewed with kview and appear weird when viewed with
kuickshow. Surely they use the same underlying libraries?
--
Angus
Re: std::string pathc
On Tue, Oct 07, 2003 at 09:43:55AM +0200, Lars Gullik Bjønnes spake thusly: > > Martin Vermeer <[EMAIL PROTECTED]> writes: > | The message is the following: > > > | In file included from math_macrotable.C:13: > | math_macrotable.h:26: `string' undeclared in namespace `_STL' > > Yes... but this is math_macrotable.h only. The others were the same. Except for one required 'using' statement. > Did you fix all the problems in one go, or did you try to recompile in > between. I fixed one at a time. Heaven knows how many times I recompiled... > My method was to begin a recombile everytime i added a Same here. Of course it might be that an added became superfluous again by a later added one... I did not go back to check that (Would Angus have a script for that?). > >> But it shouldn't really matter... strange though that STLport does not > >> forward declare std::string in about the same places as libstdc++. > > > | What does the standard say? Brokken includes in all his > | examples. > > The standard say nothing about this. In other words, a legal implementation can require #include throughout? > -- > Lgb - Martin pgp0.pgp Description: PGP signature
Re: std::string pathc
Martin Vermeer <[EMAIL PROTECTED]> writes: | In other words, a legal implementation can require #include | throughout? Yes. -- Lgb
Re: [patch]: adding transformations to InsetExternal
Asger Kunuk Alstrup wrote: > So, maybe the best feature to develop is a "Template" editing GUI in > the form of a "Wizard" which helps you make one. ;-) Maybe indeed. One thing I have been thinking might be nice is the ability to use an arbitrary _external_ renderer to visualise the contents of the inset. We already have two internal renderers --- a simple button and a graphics renderer --- with a preview renderer to follow. Do you have any feel for the feasibility of --- say --- embedding gnumeric to visualise spreadsheet data? I did a bit of a google search and it appears that Matthias Ettrich tried to generalise the KParts stuff as XParts but all references to it seemed at least two years old. -- Angus
Re: std::string pathc
Lars Gullik Bjønnes wrote: > Did you fix all the problems in one go, or did you try to recompile > in between. > My method was to begin a recombile everytime i added a It really doesn't matter though does it? Any file with a std::string arg needs to know what std::string is. I won't waste too much grey matter trying to work out where the differences lie. -- Angus
Re: The recent xpm changes
On Tue, Oct 07, 2003 at 08:49:57AM +, Angus Leeming spake thusly: > I guess that the heart of this matter is to ascertain why the files > appear fine when viewed with kview and appear weird when viewed with > kuickshow. Surely they use the same underlying libraries? I see them fine in display and in sxpm, but loading in xpaint produces a black background. Something with transparency handling? > -- > Angus > - Martin pgp0.pgp Description: PGP signature
Re: [patch]: adding transformations to InsetExternal
On Tue, 7 Oct 2003, Angus Leeming wrote: > One thing I have been thinking might be nice is the ability to use an > arbitrary _external_ renderer to visualise the contents of the inset. > We already have two internal renderers --- a simple button and a > graphics renderer --- with a preview renderer to follow. One approach would be to define a new exporting format: GUI format. > Do you have any feel for the feasibility of --- say --- embedding > gnumeric to visualise spreadsheet data? I did a bit of a google > search and it appears that Matthias Ettrich tried to generalise the > KParts stuff as XParts but all references to it seemed at least two > years old. Do the above, and then I think the better approach is just to bug the authors of such programs to make export options in the programs. And as a fall-back, why not just use a screen-shot making program? The task of designing a new XPart thing is big, and doomed to be uphill due to a multiple of different technologies used, lack of man-power to implement support for it in other applications, no buy-in from other applications, and so on. A simple export feature, however, even if it flashes a window shortly, is often a five-line patch: Open the document, save it in some useful format, and close the application again. From there, the converter business picks up the ball. Most maintainers would accept such patches. Best regards, Asger
Re: std::string pathc
Martin Vermeer wrote: > Of course it might be that an added became superfluous > again by a later added one... I did not go back to check that (Would > Angus have a script for that?). Every header file should be able to be compiled on its own. I do have a script to check that. Doing so (after updating my tree with your changes), I had to add to these files only. WordLangTuple.h frontends/Menubar.h frontends/qt2/QDocument.h frontends/qt2/qlkey.h mathed/math_gridinfo.h -- Angus
Re: [patch]: adding transformations to InsetExternal
Asger Kunuk Alstrup wrote: > A simple export feature, however, even if it flashes a window > shortly, is often a five-line patch: Open the document, save it in > some useful format, and close the application again. From there, the > converter business picks up the ball. > > Most maintainers would accept such patches. Good idea actually. And it fits nicely with another pet project I might develop --- a scrollable inset --- of use also to the math and tabular insets. -- Angus
File format changes due to Box patch
Hi Martin, please document the changes to the file format that you introduced with box in development/FORMAT. After that I will do the convertion and retroversion for lyx2lyx. -- José Abílio LyX file format cop.
Re: File format changes due to Box patch
On Tue, Oct 07, 2003 at 09:34:17AM +0100, Jose' Matos spake thusly: > > Hi Martin, > please document the changes to the file format that you introduced with box > in development/FORMAT. > > After that I will do the convertion and retroversion for lyx2lyx. > > -- > José Abílio > > LyX file format cop. José, here is the patch. I'll commit it presently if you're happy with it (and in amended form later if not). - Martin Index: FORMAT === RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/FORMAT,v retrieving revision 1.13 diff -u -p -r1.13 FORMAT --- FORMAT 21 Aug 2003 12:15:28 - 1.13 +++ FORMAT 7 Oct 2003 09:01:54 - @@ -1,5 +1,38 @@ LyX file-format changes --- +2003-10-07 Martin Vermeer <[EMAIL PROTECTED]> + + * Added box inset. File format: + + \begin_inset OvalboxBoxed/Frameless/ovalbox/Ovalbox + /Shadowbox/Doublebox + position "b"t/c/b + hor_pos "c" l/c/r/s + has_inner_box 1 1/0 + inner_pos "b" t/c/b/s + use_parbox 01/0 + width "100col%" unit+width-string + special "none" none/height/depth + /totalheight/width + height "1in"unit+width-string + height_special "totalheight"none/height/depth + /totalheight/width + collapsed false true/false + + \begin_layout Standard + + + \end_layout + + \end_inset + + This box (Frameless, has_inner_box=1, use_parbox=0) replaces + the pre-existing Minipage inset. Parameters translate as follows: + position0/1/2 -> t/c/b + inner_position 0/1/2/3 -> inner_pos c/t/b/s + height same + width same + collapsed same 2003-08-19 Michael Schmitt <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
Re: The recent xpm changes
On Tue, Oct 07, 2003 at 11:22:10AM +0300, Martin Vermeer wrote: > I see them fine in display and in sxpm, but loading in xpaint produces > a black background. Something with transparency handling? AFAIK Qt has no way to directly manipulate None and friends. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 09:40:21AM +0200, Andre Poenitz wrote: > > I have too say that I am not really in love with this menu, > > but I won't criticize it too hard, since I have nothing better to > > propose for now. I think that the fact that it appears and disappears > > contextually is not too bad if we make sure that the edit menu is > > always kept short enough so that people can spot such entries easily > > (and of course, this is a pretty good reason for moving Preference to > > Tools). > > I don't agree here. Table and math are even more integrated with LyX > than the spellchecker, yet the the spellchecker gets greyed out but > math and tables get removed. This argument would work if the rationale for the context-sensitive area was "stuff that isn't integrated as much as other stuff". But iti is not and it never was. > furthermore don't think 'weird stuff' in the third menu level of > Edit->math needs to make sense for people not using math at all. But > removing math is not ok. Ideally there wouldn't even be a third level; deep hierarchies suck. But I do not have any specific suggestions to help[1] so I won't complain about it. john [1] one possibility would be to move such esoteric stuff to /only/ the right-click context menu ... -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
std::string --with-pspell
aspell.C, aspell_local.h have been forgotten.
Is the attached patch correct (it compiles) and, if yes, can I apply it?
Jürgen.
Index: src/aspell.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/aspell.C,v
retrieving revision 1.8
diff -u -r1.8 aspell.C
--- src/aspell.C 12 Sep 2003 07:41:09 - 1.8
+++ src/aspell.C 7 Oct 2003 12:11:39 -
@@ -22,6 +22,8 @@
#include
+using std::string;
+
ASpell::ASpell(BufferParams const &, string const & lang)
: els(0), spell_error_object(0)
Index: src/aspell_local.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/aspell_local.h,v
retrieving revision 1.2
diff -u -r1.2 aspell_local.h
--- src/aspell_local.h 23 Aug 2003 00:16:06 - 1.2
+++ src/aspell_local.h 7 Oct 2003 12:11:40 -
@@ -30,7 +30,7 @@
/**
* Initialise the spellchecker with the given buffer params and language.
*/
- ASpell(BufferParams const & params, string const & lang);
+ ASpell(BufferParams const & params, std::string const & lang);
virtual ~ASpell();
@@ -50,21 +50,21 @@
virtual void accept(WordLangTuple const &);
/// return the next near miss after a MISSED result
- virtual string const nextMiss();
+ virtual std::string const nextMiss();
/// give an error message on messy exit
- virtual string const error();
+ virtual std::string const error();
private:
/// add a speller of the given language
- void addSpeller(string const & lang);
+ void addSpeller(std::string const & lang);
struct Speller {
AspellSpeller * speller;
AspellConfig * config;
};
- typedef std::map Spellers;
+ typedef std::map Spellers;
/// the spellers
Spellers spellers_;
Index: src/support/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/Makefile.am,v
retrieving revision 1.69
diff -u -r1.69 Makefile.am
--- src/support/Makefile.am 6 Oct 2003 15:43:17 - 1.69
+++ src/support/Makefile.am 7 Oct 2003 12:11:43 -
@@ -27,7 +27,7 @@
copy.C \
copied_ptr.h \
cow_ptr.h \
- debugstream,h \
+ debugstream.h \
filename.C \
filename.h \
filetools.C \
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 01:46:17PM +0100, John Levon wrote: > > I don't agree here. Table and math are even more integrated with LyX > > than the spellchecker, yet the the spellchecker gets greyed out but > > math and tables get removed. > > This argument would work if the rationale for the context-sensitive > area was "stuff that isn't integrated as much as other stuff". But iti > is not and it never was. [The argument mentioned the word 'optional' somehow IIRC...] > > furthermore don't think 'weird stuff' in the third menu level of > > Edit->math needs to make sense for people not using math at all. But > > removing math is not ok. > > Ideally there wouldn't even be a third level; deep hierarchies suck. Indeed. > But I do not have any specific suggestions to help[1] so I won't > complain about it. > > john > > [1] one possibility would be to move such esoteric stuff to /only/ the > right-click context menu ... The problem with 'right-click context menus' is that they are not as simple to implement as adding a few lines to ui/foo.ui. Show me how that works and I'll happily move most mathed editing to such a context menu. [One of the real problems with LyX UI is creating new dialogs. A lot of features is simply not visible to users as nobody went through the trouble to create an appropriate dialog. Unfortunately neither xfroms nor Qt make developing dialogs simple. (Or at least as simple as Tcl/Tk etc)] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: std::string --with-pspell
Juergen Spitzmueller wrote: > aspell.C, aspell_local.h have been forgotten. > Is the attached patch correct (it compiles) and, if yes, can I apply > it? Yes and yes. -- Angus
Re: std::string --with-pspell
Angus Leeming wrote: > Yes and yes. Done. Jürgen.
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 03:13:10PM +0200, Andre Poenitz wrote: > The problem with 'right-click context menus' is that they are not as > simple to implement as adding a few lines to ui/foo.ui. All we need is some function to return the type of the current inset. Then we can add lines for each item in a ui/context.ui > Show me how that works and I'll happily move most mathed editing to > such a context menu. Please don't - anything an average user is likely to use MUST be in the main menus. Context menus are an *additional* convenience feature not a replacement. Of course this rule is broken all over the place in most applications. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The recent xpm changes
On Tuesday 07 October 2003 12:41 pm, John Levon wrote: > On Tue, Oct 07, 2003 at 11:22:10AM +0300, Martin Vermeer wrote: > > I see them fine in display and in sxpm, but loading in xpaint produces > > a black background. Something with transparency handling? > AFAIK Qt has no way to directly manipulate None and friends. We've had None for ever and it has never been a problem before. Perhaps the question to address is "What is going wrong on RH9?" grep-ing for 'None"' in the Qt 3.0.5 sources throws up a bunch of xpm files with this attribute... Angus
Re: The recent xpm changes
Angus Leeming wrote: > We've had None for ever and it has never been a problem before. Perhaps the > question to address is "What is going wrong on RH9?" I have the same with SuSE 8.2 I seem to remember that the problem appeared after the update to QT 3.2.1 (I'm not sure though). Jürgen.
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 02:37:53PM +0100, John Levon wrote: > On Tue, Oct 07, 2003 at 03:13:10PM +0200, Andre Poenitz wrote: > > > The problem with 'right-click context menus' is that they are not as > > simple to implement as adding a few lines to ui/foo.ui. > > All we need is some function to return the type of the current inset. > Then we can add lines for each item in a ui/context.ui No problem. Inset::getInsetName() exists already and some Insets even implement it. > > Show me how that works and I'll happily move most mathed editing to > > such a context menu. > > Please don't - anything an average user is likely to use MUST be in > the main menus. Well, 100 features would most likely end up in a deep menu hierarchy, won't they? Andre'
Re: The recent xpm changes
Juergen Spitzmueller wrote: > Angus Leeming wrote: >> We've had None for ever and it has never been a problem before. >> Perhaps the question to address is "What is going wrong on RH9?" > > I have the same with SuSE 8.2 I seem to remember that the problem > appeared after the update to QT 3.2.1 (I'm not sure though). > > Jürgen. $grep -r 'None"' qt-x11-free-3.2.1/src/ qt-x11-free-3.2.1/src/styles/qwindowsstyle.cpp:". c None", [snip lots of others...] -- Angus
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 04:00:16PM +0200, Andre Poenitz wrote: > > Please don't - anything an average user is likely to use MUST be in > > the main menus. > > Well, 100 features would most likely end up in a deep menu hierarchy, > won't they? What are these 100 features average users are likely to use [often] ? john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 03:24:02PM +0100, John Levon wrote: > On Tue, Oct 07, 2003 at 04:00:16PM +0200, Andre Poenitz wrote: > > > > Please don't - anything an average user is likely to use MUST be in > > > the main menus. > > > > Well, 100 features would most likely end up in a deep menu hierarchy, > > won't they? > > What are these 100 features average users are likely to use [often] ? half a dozen formula types, half a dozen for table cell alignment, two dozen font changes macro args n functions in m CA systems 'optional' arguments for \color, \framebox etc brackets and other stuff from the math panel to have mouse-less access. ... [I guess you will cut down this list based on 'average', 'likely' and 'often'...] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [bugzilla-daemon@lyx.org: [Bug 1421] Regression: menu items vanish]
On Tue, Oct 07, 2003 at 04:49:16PM +0200, Andre Poenitz wrote: > [I guess you will cut down this list based on 'average', 'likely' and > 'often'...] Let's assume I've already done it ;) john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
(Pre) Announcment: Lyx WikiWiki site relocated
Hi I'm about to officially announce the new Lyx wiki-wiki site, the announcment in the e-mail reads as follows: -- Subject: LyX wiki site relocated to http://wiki.lyx.org/pmwiki.php The LyX wiki site has moved to its new home: http://wiki.lyx.org/pmwiki.php (it used to be http://ev-en.org/wiki/moin.cgi/LyxWikis). For the full announcement, go to: http://wiki.lyx.org/pmwiki.php/Main/Announcement The section with frequently asked questions can now be found at: http://wiki.lyx.org/pmwiki.php/FAQ -- Three questions though: * How should it be signed, suggestions please? * Send both to [EMAIL PROTECTED] and [EMAIL PROTECTED] * At the moment there's a protest against e-patents on the top of the front page, should that stay or go? Please read the more detailed info (Main/Announcement), and let me know if you have any comments (or just change it). At the moment, the only major "flaw" is that all URI's will have to include 'pmwiki.php'. I've tried to mail Lars twice without response, so he's probably too busy or unable to fix it. (see attached message below). /Christian PS. On the humorous side... some assh-e had "hacked" the front page and put a rant there. Since the wiki is version controlled, I just restored the previous version... If you'd like to see the rant, go here: http://wiki.lyx.org/pmwiki.php/Main/HomePage?action=diff (it'll be shown interlaced with the current page). -- Ph.D. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr -- Forwarded message -- Date: Sun, 5 Oct 2003 07:48:27 +0200 (CEST) From: Christian Ridderström <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Configuring the Lyx wiki site Hi Lars I would like to ask you to make five changes at wiki.lyx.org before I officially "open" the site by sending out an announcement. Please go and look at this page http://wiki.lyx.org/pmwiki.php/Test/SiteConfig and let me know if you can do this. I have tried to put concise instructions there, and I don't think it should take much time to do. /Christian -- Ph.D. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: (Pre) Announcment: Lyx WikiWiki site relocated
Christian Ridderström wrote: > Hi > > I'm about to officially announce the new Lyx wiki-wiki site, the > announcment in the e-mail reads as follows: > > -- > Subject: LyX wiki site relocated to http://wiki.lyx.org/pmwiki.php > The LyX wiki site has moved to its new home: > > http://wiki.lyx.org/pmwiki.php So you didn't succeed in your attempt to get rid of 'pmwiki.php' then? > Three questions though: > > * How should it be signed, suggestions please? The LyX team. (Like ANNOUNCE does). > * Send both to [EMAIL PROTECTED] and [EMAIL PROTECTED] Why not. > * At the moment there's a protest against e-patents on the top of > the front page, should that stay or go? Is it relevant now that the European parliament have passed the draft resolution? -- Angus
Re: (Pre) Announcment: Lyx WikiWiki site relocated
Christian Ridderström <[EMAIL PROTECTED]> writes: | At the moment, the only major "flaw" is that all URI's will have to | include 'pmwiki.php'. I've tried to mail Lars twice without response, so | he's probably too busy or unable to fix it. (see attached message below). Or didn't really try... -- Lgb
Re: (Pre) Announcment: Lyx WikiWiki site relocated
On Tue, 7 Oct 2003, Angus Leeming wrote: > So you didn't succeed in your attempt to get rid of 'pmwiki.php' then? > Lars haven't tried (see the mail he just sent). > > * How should it be signed, suggestions please? > > The LyX team. (Like ANNOUNCE does). Ok (done). > > * At the moment there's a protest against e-patents on the top of > > the front page, should that stay or go? > > Is it relevant now that the European parliament have passed the draft > resolution? It's still up to the European Commission (I'm not sure the parliament has any real power actually)... but it can go or stay as far as I'm concerned. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: (Pre) Announcment: Lyx WikiWiki site relocated
Christian Ridderström <[EMAIL PROTECTED]> writes: | On Tue, 7 Oct 2003, Angus Leeming wrote: > >> So you didn't succeed in your attempt to get rid of 'pmwiki.php' then? >> | Lars haven't tried (see the mail he just sent). But I'll try... One thing... it is possible to make navigation in the wiki easier? navigating up in the doc tree is quite hard... (you have to use in the browser) -- Lgb
Re: (Pre) Announcment: Lyx WikiWiki site relocated
On Tue, 7 Oct 2003, Lars Gullik Bjønnes wrote: > But I'll try... > > One thing... it is possible to make navigation in the wiki easier? > navigating up in the doc tree is quite hard... (you have to use > in the browser) Yes, it's possible to make it much easier. Actually, one of the reasons I wanted you to install some of the Cookbook-extensions was to let me try different for navigation. But here's what we (can) have now: o This is standard: Clicking on the Lyx logo moves you to Main.HomePage. Clicking on the name of the group (at the top of the page) moves you to the homepage of the group. o We can customize what appears at the top and at the bottom of each page (per group if we'd like to). This could be links to the more "important" pages within each group. o Using Wiki-trails is another solution, i.e. as on this page: http://wiki.lyx.org/pmwiki.php/FAQ/Internet it's the thing at the top that looks like this: << Introduction and General Information | PageList | Compability >> and it allows you to go to the previous/top/next page in the "trail". o We can put a cute table with links on each/some of the pages, e.g.: http://wiki.lyx.org/pmwiki.php/Test/UsingQuickLinks Using cookbook extensions, even more is possible. o Installing IncludePara, I could relatively easily create "sitemaps", and each page could have link to the sitemap o Other cookbook extensions, allow stuff like this: http://www.dortmans.com/ (it's probably the CSS-cookbook extension, but I'm not sure). If any of this sounds better than other stuff, let me know and I'll have a go at it. I expect the site will change quite a bit once people start to actually use it anyway. I'd especially like to know if there are sections that are more difficult than others, or if it's the site in general that's difficult. /Christian PS. As to your question about having to click "back", I didn't quite understand that. Would you like to have a link somewhere on the page that says "back"? Or do you mean that you'd like to have a link saying: Last page visited: FAQ.Introduction If it is the latter, it is being developed, but will probably require using cookies or something (which isn't being used at the moment). -- Christian Ridderström http://www.md.kth.se/~chr
watch counters go wrong
Have a look. deptherror.lyx Description: Binary data -- Lgb
Re: watch counters go wrong
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Have a look.
This seems to fix the problem:
(please verify)
? deptherror.diff
? deptherror.lyx
? kystskipper-a-1.lyx
Index: src/text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.470
diff -u -p -r1.470 text2.C
--- src/text2.C 6 Oct 2003 15:42:40 - 1.470
+++ src/text2.C 7 Oct 2003 21:40:01 -
@@ -910,7 +910,7 @@ void LyXText::setCounter(Buffer const &
&& boost::prior(pit)->getDepth() > pit->getDepth()
&& layout->labeltype != LABEL_BIBLIO) {
pit->enumdepth = depthHook(pit, ownerParagraphs(),
- pit->getDepth())->enumdepth;
+ pit->getDepth())->enumdepth;
}
// erase what was there before
@@ -938,7 +938,16 @@ void LyXText::setCounter(Buffer const &
// bufparams.user_defined_bullet(pit->itemdepth).getText());
// for now, use a static label
pit->params().labelString("*");
- textclass.counters().reset("enum");
+ switch (pit->enumdepth) {
+ case 0:
+ textclass.counters().reset("enumi");
+ case 1:
+ textclass.counters().reset("enumii");
+ case 2:
+ textclass.counters().reset("enumiii");
+ case 3:
+ textclass.counters().reset("enumiv");
+ }
} else if (layout->labeltype == LABEL_ENUMERATE) {
// FIXME
// Yes I know this is a really, really! bad solution
--
Lgb
Re: watch counters go wrong
On Tue, Oct 07, 2003 at 11:42:22PM +0200, Lars Gullik Bj?nnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | Have a look. > > This seems to fix the problem: > (please verify) I think we have least two counter bugs worth testing against on bugzilla john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch]: boost any
Angus Leeming wrote: > Lars, could I get you to apply this/contact the boost list as you > see fit? Thanks for doing that Lars. I see that the change has been committed and have noted the comment about including the appropriate header. I'll commit the changes to the lyx tree. -- Angus
Latest CVS std::string
I had to do this to compile latest CVS on Cygwin:
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Index: src/support/lyxsum.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/lyxsum.C,v
retrieving revision 1.33
diff -u -r1.33 lyxsum.C
--- src/support/lyxsum.C2003/10/06 15:43:18 1.33
+++ src/support/lyxsum.C2003/10/07 22:53:03
@@ -17,6 +17,7 @@
#include
using std::endl;
+using std::string;
// OK, this is ugly, but it is the only workaround I found to compile
// with gcc (any version) on a system which uses a non-GNU toolchain.
Index: src/support/os_win32.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/os_win32.C,v
retrieving revision 1.12
diff -u -r1.12 os_win32.C
--- src/support/os_win32.C 2003/08/23 00:16:57 1.12
+++ src/support/os_win32.C 2003/10/07 22:53:03
@@ -23,6 +23,7 @@
using namespace lyx::support;
using std::endl;
+using std::string;
namespace {
[patch] InsetExternal transformations
It's been a long time coming, but is now committed. Patch attached FYI. -- Angus external.diff.bz2 Description: BZip2 compressed data
Re: watch counters go wrong
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Oct 07, 2003 at 11:42:22PM +0200, Lars Gullik Bj?nnes wrote: > >> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: >> >> | Have a look. >> >> This seems to fix the problem: >> (please verify) > | I think we have least two counter bugs worth testing against on bugzilla I just grabbed one of those. (1025) Which one is the other? -- Lgb
Re: [patch]: boost any
Angus Leeming <[EMAIL PROTECTED]> writes: | Angus Leeming wrote: >> Lars, could I get you to apply this/contact the boost list as you >> see fit? > | Thanks for doing that Lars. I see that the change has been committed | and have noted the comment about including the appropriate header. > | I'll commit the changes to the lyx tree. Ok. -- Lgb
"fdesign -convert form_external.fd}" failed. Please investigate.
This is the end of the 'make' for current LyX/CVS: [...snip...] /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I./.. -I../../../../src -I.. -I/opt/include -I/usr/local/include -I/usr/X11R6/include -g -O -fno-exceptions -W -Wall -MT form_ert.lo -MD -MP -MF .deps/form_ert.Tpo -c form_ert.C echo timestamp > form_ert.lo /bin/sh ./fdfix.sh form_external.fd In TypeValue [fd_objects.c 634] type is unknown In FindClassStruct [fd_objects.c 124] Can't find class 0 unknown class 0 Segmentation fault (core dumped) "fdesign -convert form_external.fd}" failed. Please investigate. make[6]: *** [form_external.C] Error 1 Is this a bug in LyX or a problem with Xforms? Maybe this form_external.fd has been created with a too new/old version of fdesign? I'm using xforms version 1.0.2, but I don't think that fdesign differs from the latest official release, or has it? I have then upgraded to latest Xforms/CVS, but still got exactly the same error. Rob.
Re: "fdesign -convert form_external.fd}" failed. Please investigate.
Rob Lahaye wrote: > > > This is the end of the 'make' for current LyX/CVS: > Ah, hold on for a moment; this is possibly due to my own changes to form_external.fd! Forgot about that. I'll investigate myself first. Sorry for the noise. Rob.
[PATCH] A local socket lyxserver.
Hello,
I wrote a simple local socket interface for lyx that compiles and runs
well in Linux with gcc 3.3 (Debian unstable) with the purpose of getting
inverse dvi search working, for witch I will send a patch in my next
e-mail.
It consists of two classes:
LyXDataSocket - this class has a socket in the connected state and two
functions readln() and writeln() for line buffered IO.
LyXServerSocket - this class has a socket in the listening state. Each
time a new connection arrives, it allocates a new LyXDataSocket.
These are intended to substitute the lyxserver based on pipes, but can
coexist with it. Up to now, the socket server is used only by the xforms
frontend. Of course, to substitute the pipe lixserver, it has to be ported
to qt and also run on all the operating systems the pipe lyxserver runs.
To compile, apply the patch lyxsocket.diff, copy
LyXSocket.{C,h} in src
socktools.{C,h} in src/support
and run autogen and configure. Also attached is the corresponding client
lyxclient.C. Compile it with
g++ -o lyxclient lyxclient.C
Once lyx starts a socket special file named lyxsocket will be created on
its temporary directory, say
/tmp/lyx_tmpdir511223hyx2/lyxsocket
To send only one comand to this running lyx, use
lyxclient -a /tmp/lyx_tmpdir511223hyx2/lyxsocket -c
Several lyxes can run at the same time! To send more than one command,
don't use the switch -c and type directly on lyxclient standard input. If
the -a switch is not used, lyxclient will try to find a running lyx and
connect to it. 'lyxclient -h' should provide a comprehensive help.
If this patch gets accepted, I will provide Changelog entries and also
write the lyxclient manpage.
Regards,
João.
/**
* \file lyxclient.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author João Luis M. Assirati
*
* Full author contact details are available in file CREDITS.
*/
#include
#include
#include
#include
// getpid(), getppid()
#include
#include
// select()
#include
// opendir(), closedir(), readdir()
#include
#include
// stat()
#include
// socket(), connect()
#include
#include
// fcntl()
#include
using std::string;
using std::vector;
using std::cout;
using std::cerr;
using std::cin;
using std::endl;
// support
namespace support
{
string itoa(unsigned int i)
{
string str;
if(!i) {
str = "0";
} else {
while((0 < i) && (i <= 9)) {
str = static_cast('0' + i % 10) + str;
i /= 10;
}
}
return str;
}
bool prefixIs(string const & a, string const & pre)
{
char const * p_a = a.c_str();
char const * p_pre = pre.c_str();
while ((*p_a != '\0') && (*p_pre != '\0') && (*p_a == *p_pre)) {
++p_a;
++p_pre;
}
if (*p_pre == '\0') return true;
return false;
}
// Parts stolen from lyx::support::DirList()
// Returns pathnames begining with dir and ending with
// pathname separator (/ in unix)
vector lyxSockets(string const & dir, string const & pid)
{
vector dirlist;
DIR * dirp = ::opendir(dir.c_str());
if (!dirp) {
cerr << "lyxclient: Could not read dir " << dir
<< ": " << strerror(errno);
return dirlist;
}
dirent * dire;
while ((dire = ::readdir(dirp))) {
string const fil = dire->d_name;
if (prefixIs(fil, "lyx_tmpdir" + pid)) {
string lyxsocket = dir + '/' + fil + "/lyxsocket";
struct stat status;
// not checking if it is a socket -- just if it exists
if (!::stat(lyxsocket.c_str(), &status)) {
dirlist.push_back(lyxsocket);
}
}
}
::closedir(dirp);
return dirlist;
}
namespace socktools
{
int connect(string const & name)
{
int fd; // File descriptor for the socket
sockaddr_un addr; // Structure that hold the socket address
// char sun_path[108]
string::size_type len = name.size();
if(len > 107) {
cerr << "lyxclient: Socket address '" << name
<< "' too long." << endl;
return -1;
}
// Synonims for AF_UNIX are AF_LOCAL and AF_FILE
addr.sun_family = AF_UNIX;
name.copy(addr.sun_path, 107);
addr.sun_path[len] = '\0';
if((fd = ::socket(PF_UNIX, SOCK_STREAM, 0))== -1) {
cerr << "lyxclient: Could not create socket: "
<< strerror(errno) << endl;
return -1;
}
if(::connect(fd, (struct sockaddr *)&addr, SUN_LEN(&addr)) == -1) {
cerr << "lyxclient
[PATCH] Inverse DVI search
Hello again,
This patch implements Inverse DVI search for lyx. It needs my previous
patch for the socket lyxserver. To use it, define
xdvi -editor 'lyxclient -a $$s -g %f %l'
as the viewer for the DVI format and
latex --src-specials
as the latex->DVI converter.
As with the previous, I will provide Changelog entries if this patch gets
accepted.
Regards,
João.
Index: src/format.C
===
RCS file: /cvs/lyx/lyx-devel/src/format.C,v
retrieving revision 1.19
diff -u -r1.19 format.C
--- src/format.C 2003/10/06 15:42:15 1.19
+++ src/format.C 2003/10/08 05:11:12
@@ -16,6 +16,7 @@
#include "lyxrc.h"
#include "debug.h"
#include "gettext.h"
+#include "LyXSocket.h"
#include "frontends/Alert.h" //to be removed?
@@ -36,11 +37,13 @@
using std::string;
+extern LyXServerSocket * lyxsocket;
namespace {
string const token_from("$$i");
string const token_path("$$p");
+string const token_socket("$$s");
} //namespace anon
@@ -196,7 +199,7 @@
command = subst(command, token_from,
QuoteName(OnlyFilename(filename)));
command = subst(command, token_path, QuoteName(OnlyPath(filename)));
-
+ command = subst(command, token_socket, QuoteName(lyxsocket->address()));
lyxerr[Debug::FILES] << "Executing command: " << command << std::endl;
buffer.message(_("Executing command: ") + command);
Index: src/bufferlist.C
===
RCS file: /cvs/lyx/lyx-devel/src/bufferlist.C,v
retrieving revision 1.134
diff -u -r1.134 bufferlist.C
--- src/bufferlist.C 2003/10/06 15:42:06 1.134
+++ src/bufferlist.C 2003/10/08 05:11:16
@@ -37,6 +37,7 @@
using lyx::support::MakeDisplayPath;
using lyx::support::OnlyFilename;
using lyx::support::removeAutosaveFile;
+using lyx::support::prefixIs;
using std::endl;
using std::find;
@@ -326,6 +327,17 @@
find_if(bstore.begin(), bstore.end(),
lyx::compare_memfun(&Buffer::fileName, s));
return it != bstore.end() ? (*it) : 0;
+}
+
+
+Buffer * BufferList::getBufferFromTmp(string const & s)
+{
+ BufferStorage::iterator it = bstore.begin();
+ BufferStorage::iterator end = bstore.end();
+ for (; it < end; ++it)
+ if (prefixIs(s, (*it)->temppath()))
+ return *it;
+ return 0;
}
Index: src/bufferlist.h
===
RCS file: /cvs/lyx/lyx-devel/src/bufferlist.h,v
retrieving revision 1.45
diff -u -r1.45 bufferlist.h
--- src/bufferlist.h 2003/10/07 06:45:24 1.45
+++ src/bufferlist.h 2003/10/08 05:11:18
@@ -68,6 +68,8 @@
Buffer * getBuffer(std::string const &);
/// returns a pointer to the buffer with the given number.
Buffer * getBuffer(unsigned int);
+ /// returns a pointer to the buffer whose temppath matches the string
+ Buffer * BufferList::getBufferFromTmp(std::string const &);
/// reset current author for all buffers
void setCurrentAuthor(std::string const & name, std::string const & email);
Index: src/lyxfunc.C
===
RCS file: /cvs/lyx/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.509
diff -u -r1.509 lyxfunc.C
--- src/lyxfunc.C 2003/10/07 07:42:11 1.509
+++ src/lyxfunc.C 2003/10/08 05:11:25
@@ -73,6 +73,7 @@
#include "support/path_defines.h"
#include "support/tostr.h"
#include "support/std_sstream.h"
+#include "support/os.h"
using bv_funcs::apply_freefont;
using bv_funcs::changeDepth;
@@ -104,6 +105,8 @@
using lyx::support::token;
using lyx::support::trim;
using lyx::support::user_lyxdir;
+using lyx::support::prefixIs;
+using lyx::support::os::getTmpDir;
using std::endl;
using std::make_pair;
@@ -1364,14 +1367,20 @@
int row;
istringstream istr(argument.c_str());
istr >> file_name >> row;
- // Must replace extension of the file to be .lyx and get full path
- string const s(ChangeExtension(file_name, ".lyx"));
-
- // Either change buffer or load the file
- if (bufferlist.exists(s)) {
- view()->buffer(bufferlist.getBuffer(s));
+ if (prefixIs(file_name, getTmpDir())) {
+ // Needed by inverse dvi search. If it is a file
+ // in tmpdir, call the apropriated function
+ view()->buffer(bufferlist.getBufferFromTmp(file_name));
} else {
- view()->loadLyXFile(s);
+ // Must replace extension of the file to be .lyx
+ // and get full path
+ string const s(ChangeExtension(file_name, ".lyx"));
+ // Either change buffer or load the file
+ if (bufferlist.exists(s)) {
+view()->buffer(bufferlist.getBuffer(s));
+ } else {
+view()->loadLyXFile(s);
+ }
}
view()->setCursorFromRow(row);
