Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

 | Personally I'm used to the '*' now... I think of it as a footnote marker 
 | that indicates that it's the unnumbered version of the environment.
 | Additionally, it makes remembering the keyboard shortcuts pretty easy.
 
 So... is Standard numbered or not?

No idea... based on 'M-p s' I'd say it's not numbered ;-)
But I have a feeling I'm missing your point...

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

 I would never make it look like that.

besides the fact that (Numbered)/(Unnumbered) isn't aligned to the right, 
how would you make it look?

 And the (Numbered) (Unnumbered) should certainly _not_ be part of any 
 layout file. (but I understand you do this to show how it would look only)

yup... just a quick'n'dirty mock-up

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: Most wanted feature: Spell as you type

[Janus Sandsgaard]

On Thu, 1 Jan 2004, Fernando Perez wrote:

 Since I don't read Danish, I can't comment on any details, and you may
 already have done this.

I didn´t expect anyone to read Danish. It was more a show off. ;-)

 But in case you don't know about it, are you aware of pybliographic?

Oh yes, and I am using that allready. Just need flyspell...

-j

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 00:56, Lars Gullik Bjnnes wrote:
 This patch removes the distance and advance functions from
 PosIterator.[Ch] and makes the code use std::distance and std::advance
 instead.

Cool.

 It also makes PosIterator and ParIterator derive from std::iterator so
 that the work properly with std stl algorithms.

This is very nice. Btw, don't we need to implement operator* to be fully 
compliant (or does std::iterator implements a trivial one)?

 Please have a look.

Nice!

PS1: Maybe I'd define the value_type differently, but we can change it 
later if we need.

PS2: I was thinking (for later) to implement several pseudo-iterators on 
top of PosIterator for the benefit of search  replace. For instance we 
could have one of these that adds some special symbols for inset begin 
and inset end or inset type, layouts, formating etc, so we can do more 
complex searches fi wanted. What do people think about that?

Alfredo


PS: wish you all happy festivities!

Re: Naming of layouts - numbered/unnumbered

[Lars Gullik Bjønnes]

Christian Ridderström [EMAIL PROTECTED] writes:

| On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

 I would never make it look like that.

| besides the fact that (Numbered)/(Unnumbered) isn't aligned to the right, 
| how would you make it look?

Probably only have one version, and the possibility to choose if the
unnumbered version should be used. Or switch after the numbered one
has been applied. So the marker in the drop-down should only tell  if
the layout exists in both numbered and unnumbered versions.

C-u M-p 2  - unnumbered section f.ex.
M-p 2  - numbered section

C-u in here is the universal-argument

(I know that this speaks against what I originally said, but the
important part is to have only one def. in hte .layout files.)
(Also it would be nice to make the drop-down a bit shorter)

-- 
Lgb

Re: [patch] iterator work

[Lars Gullik Bjønnes]

Alfredo Braunstein [EMAIL PROTECTED] writes:

| This is very nice. Btw, don't we need to implement operator* to be fully 
| compliant

Yes, we do.
(I'll just do that.)

| (or does std::iterator implements a trivial one)?

No, I don't think so.


 Please have a look.

| Nice!

| PS1: Maybe I'd define the value_type differently, but we can change it 
| later if we need.

suggestions?

| PS2: I was thinking (for later) to implement several
| pseudo-iterators on 

What will be pseudo about them? They should follow the iterator
requirements.
 
-- 
Lgb

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 13:30, you wrote:

 I am almost inclined to say that the value_type should be

 tupleParagraphList, ParagraphList::iterator, lyx::pos_type

Why? It seems to me that Paragraph  + lyx::pos_type is enough to describe 
the paragraph position the iterator is pointing to. 

If we really want to be precise, we could as well use boost::optional or 
equivalent to define a type that describe the object it points to: a 
char/inset code/paragraph end. What do you think?

 There is also a conceptual problem since PosIterator is both used as a
 iterator and as a container. Not really nice.

Where?

Alfredo

Re: [patch] iterator work

[Lars Gullik Bjønnes]

Alfredo Braunstein [EMAIL PROTECTED] writes:

| On Saturday 03 January 2004 13:30, you wrote:

 I am almost inclined to say that the value_type should be

 tupleParagraphList, ParagraphList::iterator, lyx::pos_type

| Why? It seems to me that Paragraph  + lyx::pos_type is enough to describe 
| the paragraph position the iterator is pointing to. 

you are right.


| If we really want to be precise, we could as well use boost::optional or 
| equivalent to define a type that describe the object it points to: a 
| char/inset code/paragraph end. What do you think?

I do not quite understand

 There is also a conceptual problem since PosIterator is both used as a
 iterator and as a container. Not really nice.

| Where?

the asPosIterator function.

I am trying to rewrite that so it does not require to be a friend.
Friends often is the easy way out... completely by passes all access
control.

-- 
Lgb

Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

 Probably only have one version, and the possibility to choose if the
 unnumbered version should be used. Or switch after the numbered one
 has been applied. So the marker in the drop-down should only tell  if
 the layout exists in both numbered and unnumbered versions.

I see... the marker could be a '*', just to confuse everybody ;-)
and a keyboard shortcut to toggle numbered/unnumbered could be M-p *

Hmm... the dropdown need to indicate what kind this is, maybe like this:
# Section   = numbered section
* Section   = unnumbered section

where the existance of either a '#' or a '*' indicates that this 
environment exists as both numbered and unnumbered.

 C-u M-p 2  - unnumbered section f.ex.
 M-p 2  - numbered section
 
 C-u in here is the universal-argument

Ok, Emacs style, fine by me, it might be difficult to explain to 
someone who don't use Emacs though. Oops.. you must be using the Emacs 
shortcuts, because C-u gives me underline (cua.bind).

 (Also it would be nice to make the drop-down a bit shorter)

Definitely... the n:o environments in Koma Letter v.2 is huge now...

Hmm, could it be an idea to have two drop-downs? One for standard 
environments, and one for environments that are more class specific?
Alternatively, don't put all environments in the drop-down, and add a 
button for showing a dialog with a list of all environments.

/Christian


-- 
Christian Ridderström   http://www.md.kth.se/~chr

New wiki page with links to LyX internet resources

[Christian Ridderström]

Hi

I've created a wiki page here

http://wiki.lyx.org/pmwiki.php/LyX/InternetResources

with links to various resources. It was quite educational, I was 
pleasantly surprised by the web-interface at gmane.org for reading 
groups etc. At gmane.org I also discovered another mailing list: french
that isn't mentioned on
http://www.lyx.org/internet/mailing.php3

There are a few questions regarding the 'french' list that I'd like to 
verify:
 * The volume is... medium?
 * The mail address is [EMAIL PROTECTED]

And a more general question:
 * Is it impossible to send to [EMAIL PROTECTED] directly?
 * Can anyone send to [EMAIL PROTECTED]

Finally, I've also added inter-map prefixes for the lists at gmane. This 
means that you can refer to post n:o 33100 on the users list like this:
LyxUsersPost:33100

see http://wiki.lyx.org/pmwiki.php/Tips/UsingMakefileToExportPDF for an 
example.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 14:03, Lars Gullik Bjønnes wrote:
 | Why? It seems to me that Paragraph  + lyx::pos_type is enough to
 | describe the paragraph position the iterator is pointing to.

 you are right.

 | If we really want to be precise, we could as well use boost::optional
 | or equivalent to define a type that describe the object it points
 | to: a char/inset code/paragraph end. What do you think?

 I do not quite understand

What do you expect from a PosIterator dereference? A char OR inset OR
paragraph end. So we can have a kind of union (but type-safer: I thought
that we can do something like this with boost::optional or some other
boost tool but I can be wrong).

  There is also a conceptual problem since PosIterator is both used as
  a iterator and as a container. Not really nice.
 |
 | Where?

 the asPosIterator function.

 I am trying to rewrite that so it does not require to be a friend.
 Friends often is the easy way out... completely by passes all access
 control.

Agreed, although is a small piece of code an so is easily auditable.
For LCursor we have exactly the same problem but is solved without
friendship (in lockPath, that does the work formerly done by asCursor)
because LCursor offers direct access to the container push function: this
is more dangerous IMO.

I still don't quite get why PosIterator is used as a container in that
function, but I agree that friends are bad in general.

Alfredo

the point with pimpls.

[Lars Gullik Bjønnes]

I know that I am the one who began introducing pimpls to lyx. After
that I have become quite wary of them... and feel more and more that
you should have a good reason to use them. 

This boils down to: (right now) What is the use of the pimpl in
ParIterator?

I have a patch where I remove it, get rid of asPosIterator, etc.
I think it is nice and it makes the code size smaller (should be
faster as well.)
This is with gcc 3.4 prerelease and cvs boost.

? 1
Index: BranchList.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BranchList.C,v
retrieving revision 1.10
diff -u -p -b -r1.10 BranchList.C
Index: PosIterator.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/PosIterator.C,v
retrieving revision 1.5
diff -u -p -b -r1.5 PosIterator.C
--- PosIterator.C	3 Dec 2003 18:17:15 -	1.5
+++ PosIterator.C	3 Jan 2004 14:18:14 -
@@ -26,6 +26,58 @@
 
 using boost::prior;
 
+
+PosIterator::PosIterator(ParagraphList * pl,
+			 ParagraphList::iterator pit,
+			 lyx::pos_type pos)
+{
+	stack_.push_back(PosIteratorItem(pl, pit, pos));
+}
+
+
+PosIterator::PosIterator(BufferView  bv)
+{
+	LyXText * text = bv.getLyXText();
+	lyx::pos_type pos = text-cursor.pos();
+	ParagraphList::iterator pit = text-cursorPar();
+
+	ParIterator par = bv.buffer()-par_iterator_begin();
+	ParIterator end = bv.buffer()-par_iterator_end();
+	for ( ; par != end; ++par) {
+		if (par.pit() == pit)
+			break;
+	}
+
+	setFrom(par, pos);
+}
+
+
+PosIterator::PosIterator(ParIterator const  par, lyx::pos_type pos)
+{
+	setFrom(par, pos);
+}
+
+
+void PosIterator::setFrom(ParIterator const  par, lyx::pos_type pos)
+{
+	BOOST_ASSERT(par.size()  0);
+
+	ParIterator::PosHolder const  ph = par.positions();
+
+	int const last = par.size() - 1;
+	for (int i = 0; i  last; ++i) {
+		ParPosition const  pp = ph[i];
+		stack_.push_back(
+			PosIteratorItem(const_castParagraphList *(pp.plist),
+	pp.pit, (*pp.it)-pos, *pp.index + 1));
+	}
+	ParPosition const  pp = ph[last];
+	stack_.push_back(
+		PosIteratorItem(const_castParagraphList *(pp.plist), pp.pit, pos, 0));
+}
+
+
+
 PosIterator  PosIterator::operator++()
 {
 	BOOST_ASSERT(!stack_.empty());
@@ -95,15 +147,8 @@ PosIterator  PosIterator::operator--()
 }
 
 
-bool operator!=(PosIterator const  lhs, PosIterator const  rhs)
-{
-	return !(lhs == rhs);
-}
-
-
 bool operator==(PosIterator const  lhs, PosIterator const  rhs)
 {
-	
 	PosIteratorItem const  li = lhs.stack_.back();
 	PosIteratorItem const  ri = rhs.stack_.back();
 	
@@ -118,53 +163,10 @@ bool PosIterator::at_end() const
 }
 
 
-PosIterator::PosIterator(ParagraphList * pl, ParagraphList::iterator pit,
-			 lyx::pos_type pos)
-{
-	stack_.push_back(PosIteratorItem(pl, pit, pos));
-}
-
-
-PosIterator::PosIterator(BufferView  bv)
-{
-	LyXText * text = bv.getLyXText();
-	lyx::pos_type pos = text-cursor.pos();
-	ParagraphList::iterator pit = text-cursorPar();
-	
-	ParIterator par = bv.buffer()-par_iterator_begin();
-	ParIterator end = bv.buffer()-par_iterator_end();
-	for ( ; par != end; ++par) {
-		if (par.pit() == pit)
-			break;
-	}
-
-	operator=(par.asPosIterator(pos));
-}
-
-
 InsetOld * PosIterator::inset() const
 {
 	if (stack_.size() == 1)
 		return 0;
 	PosIteratorItem const  pi = stack_[stack_.size() - 2];
 	return pi.pit-getInset(pi.pos);
-}
-
-
-int distance(PosIterator const  cur, PosIterator const  end)
-{
-	PosIterator p = cur;
-	int count = 0;
-	for (; p != end; ++p, ++count)
-		;
-	return count;
-}
-
-
-void advance(PosIterator  cur, int howmuch)
-{
-	for (int i = 0; i  howmuch; ++i)
-		++cur;
-	for (int i = 0; i  howmuch; --i)
-		--cur;
 }
Index: PosIterator.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/PosIterator.h,v
retrieving revision 1.5
diff -u -p -b -r1.5 PosIterator.h
--- PosIterator.h	7 Nov 2003 09:40:48 -	1.5
+++ PosIterator.h	3 Jan 2004 14:18:14 -
@@ -36,14 +36,18 @@ struct PosIteratorItem 
 };
 
 
-class PosIterator
+class PosIterator : public std::iterator
+	std::bidirectional_iterator_tag,
+	ParagraphList::value_type
 {
 public:
+	// Creates a singular.
+	PosIterator() {};
+
 	PosIterator(BufferView  bv);
-	PosIterator(ParIterator  par, lyx::pos_type pos);
 	PosIterator(ParagraphList * pl, ParagraphList::iterator pit,
 		lyx::pos_type pos);
-	PosIterator(ParIterator const  parit, lyx::pos_type p);
+	PosIterator(ParIterator const  par, lyx::pos_type pos);
 	PosIterator  operator++();
 	PosIterator  operator--();
 	friend bool operator==(PosIterator const , PosIterator const );
@@ -52,20 +56,24 @@ public:
 	lyx::pos_type pos() const { return stack_.back().pos; }
 	bool at_end() const;
 	InsetOld * inset() const;
-	friend PosIterator ParIterator::asPosIterator(lyx::pos_type) const;
+//	friend PosIterator ParIterator::asPosIterator(lyx::pos_type) const;
 	friend ParIterator::ParIterator(PosIterator const );
 	

kde-apps.org

[Juergen Spitzmueller]

FYI: I've added LyX to www.kde-apps.org, which seems to be the successor of 
the recently deceased apps.kde.com:
http://www.kde-apps.org/content/show.php?content=9811

Please feel free to suggest changes, screenshots etc.

Jürgen.

Re: QT-screen-fonts

[Lars Gullik Bjønnes]

Kornel Benko [EMAIL PROTECTED] writes:

| -BEGIN PGP SIGNED MESSAGE-

| Hi,
| I would like to have this patch in.
| The reason is:
| There is no such font family like serif, sans or monospace
| in QT.
| Replacing them with Times New Roman, Arial and Courier
| leads to a Version which does not crash and looks fine.

Are you confident that this will work on most QT installations?

-- 
Lgb

Re: QT-screen-fonts

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Samstag, 3. Januar 2004 17:53, Lars Gullik Bjønnes wrote:
 Kornel Benko [EMAIL PROTECTED] writes:
 
 | -BEGIN PGP SIGNED MESSAGE-
 
 | Hi,
 | I would like to have this patch in.
 | The reason is:
 | There is no such font family like serif, sans or monospace
 | in QT.
 | Replacing them with Times New Roman, Arial and Courier
 | leads to a Version which does not crash and looks fine.
 
 Are you confident that this will work on most QT installations?

Unfortunatelly I am not :(. Being a non-expert on QT.

Sorry.
Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iQCVAwUBP/b5X7ewfbDGmeqhAQGAIgP8CMz9vFnRPGtNX5U++pDAU1/jmP8GMDcF
fDxgW0LB931zAp4uTz855vuzADqSD4+wA16rWdElZgRwvrf5D9IIu2kDAZL4yOGC
rA5/vaARve2KmjUQH7pZBp9wtTioQIK5ISchw1axaz43+VGJA0fggP399PT72f7c
p3Xxlp86VSA=
=SWV1
-END PGP SIGNATURE-

Re: QT-screen-fonts

[Lars Gullik Bjønnes]

Kornel Benko [EMAIL PROTECTED] writes:

| On Samstag, 3. Januar 2004 17:53, Lars Gullik Bjønnes wrote:
 Kornel Benko [EMAIL PROTECTED] writes:
 
 | -BEGIN PGP SIGNED MESSAGE-
 
 | Hi,
 | I would like to have this patch in.
 | The reason is:
 | There is no such font family like serif, sans or monospace
 | in QT.
 | Replacing them with Times New Roman, Arial and Courier
 | leads to a Version which does not crash and looks fine.
 
 Are you confident that this will work on most QT installations?

| Unfortunatelly I am not :(. Being a non-expert on QT.

Then we should investigate a bit before applying this.
Try to get some people on different systems to try your patch.

| Sorry.

no need for that.

-- 
Lgb

Re: Most wanted feature: Spell as you type

[Christian Ridderström]

Hi Janus

In order to not lose the thoughts in the mails, I put some notes here:

http://wiki.lyx.org/pmwiki.php/Devel/SpellCheckAsYouType

but I guess it needs a bit of structuring. And I might have missed 
important things etc. (I've only looked at teh mails in the user's list 
for instance).

The actual issue would probably benefit from a clearly defined suggestion 
of how the 'check as you type' mode should work,  and how it should be 
represented on the screen.

Then this suggestion could be discussed, to see what people think about 
it. Oh, and finally, an entry needs to be added to the bugzilla so that 
this isn't forgotten (unless a developer immediately starts working on 
this).

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

> | Personally I'm used to the '*' now... I think of it as a footnote marker 
> | that indicates that it's the unnumbered version of the environment.
> | Additionally, it makes remembering the keyboard shortcuts pretty easy.
> 
> So... is "Standard" numbered or not?

No idea... based on 'M-p s' I'd say it's not numbered ;-)
But I have a feeling I'm missing your point...

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

> I would never make it look like that.

besides the fact that (Numbered)/(Unnumbered) isn't aligned to the right, 
how would you make it look?

> And the (Numbered) (Unnumbered) should certainly _not_ be part of any 
> layout file. (but I understand you do this to show how it would look only)

yup... just a quick'n'dirty mock-up

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: Most wanted feature: Spell as you type

[Janus Sandsgaard]

On Thu, 1 Jan 2004, Fernando Perez wrote:

> Since I don't read Danish, I can't comment on any details, and you may
> already have done this.

I didn´t expect anyone to read Danish. It was more a show off. ;-)

> But in case you don't know about it, are you aware of pybliographic?

Oh yes, and I am using that allready. Just need flyspell...

-j

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 00:56, Lars Gullik BjÃnnes wrote:
> This patch removes the distance and advance functions from
> PosIterator.[Ch] and makes the code use std::distance and std::advance
> instead.

Cool.

> It also makes PosIterator and ParIterator derive from std::iterator so
> that the work properly with std stl algorithms.

This is very nice. Btw, don't we need to implement operator* to be fully 
compliant (or does std::iterator implements a trivial one)?

> Please have a look.

Nice!

PS1: Maybe I'd define the value_type differently, but we can change it 
later if we need.

PS2: I was thinking (for later) to implement several pseudo-iterators on 
top of PosIterator for the benefit of search & replace. For instance we 
could have one of these that adds some special symbols for "inset begin" 
and "inset end" or "inset type", layouts, formating etc, so we can do more 
complex searches fi wanted. What do people think about that?

Alfredo


PS: wish you all happy festivities!

Re: Naming of layouts - numbered/unnumbered

[Lars Gullik Bjønnes]

Christian Ridderström <[EMAIL PROTECTED]> writes:

| On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:
>
>> I would never make it look like that.
>
| besides the fact that (Numbered)/(Unnumbered) isn't aligned to the right, 
| how would you make it look?

Probably only have one version, and the possibility to choose if the
unnumbered version should be used. Or switch after the numbered one
has been applied. So the marker in the drop-down should only tell  if
the layout exists in both numbered and unnumbered versions.

C-u M-p 2  -> unnumbered section f.ex.
M-p 2  -> numbered section

C-u in here is the "universal-argument"

(I know that this speaks against what I originally said, but the
important part is to have only one def. in hte .layout files.)
(Also it would be nice to make the drop-down a bit shorter)

-- 
Lgb

Re: [patch] iterator work

[Lars Gullik Bjønnes]

Alfredo Braunstein <[EMAIL PROTECTED]> writes:

| This is very nice. Btw, don't we need to implement operator* to be fully 
| compliant

Yes, we do.
(I'll just do that.)

| (or does std::iterator implements a trivial one)?

No, I don't think so.

>
>> Please have a look.
>
| Nice!
>
| PS1: Maybe I'd define the value_type differently, but we can change it 
| later if we need.

suggestions?

| PS2: I was thinking (for later) to implement several
| pseudo-iterators on 

What will be pseudo about them? They should follow the iterator
requirements.
 
-- 
Lgb

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 13:30, you wrote:

> I am almost inclined to say that the value_type should be
>
> tuple

Why? It seems to me that Paragraph & + lyx::pos_type is enough to describe 
the paragraph position the iterator is pointing to. 

If we really want to be precise, we could as well use boost::optional or 
equivalent to define a type that describe the "object" it points to: a 
char/inset code/paragraph end. What do you think?

> There is also a conceptual problem since PosIterator is both used as a
> iterator and as a container. Not really nice.

Where?

Alfredo

Re: [patch] iterator work

[Lars Gullik Bjønnes]

Alfredo Braunstein <[EMAIL PROTECTED]> writes:

| On Saturday 03 January 2004 13:30, you wrote:
>
>> I am almost inclined to say that the value_type should be
>>
>> tuple
>
| Why? It seems to me that Paragraph & + lyx::pos_type is enough to describe 
| the paragraph position the iterator is pointing to. 

you are right.

>
| If we really want to be precise, we could as well use boost::optional or 
| equivalent to define a type that describe the "object" it points to: a 
| char/inset code/paragraph end. What do you think?

I do not quite understand

>> There is also a conceptual problem since PosIterator is both used as a
>> iterator and as a container. Not really nice.
>
| Where?

the asPosIterator function.

I am trying to rewrite that so it does not require to be a friend.
Friends often is the easy way out... completely by passes all access
control.

-- 
Lgb

Re: Naming of layouts - numbered/unnumbered

[Christian Ridderström]

On Sat, 3 Jan 2004, Lars Gullik Bjønnes wrote:

> Probably only have one version, and the possibility to choose if the
> unnumbered version should be used. Or switch after the numbered one
> has been applied. So the marker in the drop-down should only tell  if
> the layout exists in both numbered and unnumbered versions.

I see... the marker could be a '*', just to confuse everybody ;-)
and a keyboard shortcut to toggle numbered/unnumbered could be M-p *

Hmm... the dropdown need to indicate what kind this is, maybe like this:
# Section   => numbered section
* Section   => unnumbered section

where the existance of either a '#' or a '*' indicates that this 
environment exists as both numbered and unnumbered.

> C-u M-p 2  -> unnumbered section f.ex.
> M-p 2  -> numbered section
> 
> C-u in here is the "universal-argument"

Ok, Emacs style, fine by me, it might be difficult to explain to 
someone who don't use Emacs though. Oops.. you must be using the Emacs 
shortcuts, because C-u gives me underline (cua.bind).

> (Also it would be nice to make the drop-down a bit shorter)

Definitely... the n:o environments in Koma Letter v.2 is huge now...

Hmm, could it be an idea to have two drop-downs? One for standard 
environments, and one for environments that are more class specific?
Alternatively, don't put all environments in the drop-down, and add a 
button for showing a dialog with a list of all environments.

/Christian


-- 
Christian Ridderström   http://www.md.kth.se/~chr

New wiki page with links to LyX internet resources

[Christian Ridderström]

Hi

I've created a wiki page here

http://wiki.lyx.org/pmwiki.php/LyX/InternetResources

with links to various resources. It was quite educational, I was 
pleasantly surprised by the web-interface at gmane.org for reading 
groups etc. At gmane.org I also discovered another mailing list: french
that isn't mentioned on
http://www.lyx.org/internet/mailing.php3

There are a few questions regarding the 'french' list that I'd like to 
verify:
 * The volume is... medium?
 * The mail address is [EMAIL PROTECTED]

And a more general question:
 * Is it impossible to send to [EMAIL PROTECTED] directly?
 * Can anyone send to [EMAIL PROTECTED]

Finally, I've also added inter-map prefixes for the lists at gmane. This 
means that you can refer to post n:o 33100 on the users list like this:
LyxUsersPost:33100

see http://wiki.lyx.org/pmwiki.php/Tips/UsingMakefileToExportPDF for an 
example.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: [patch] iterator work

[Alfredo Braunstein]

On Saturday 03 January 2004 14:03, Lars Gullik Bjønnes wrote:
> | Why? It seems to me that Paragraph & + lyx::pos_type is enough to
> | describe the paragraph position the iterator is pointing to.
>
> you are right.
>
> | If we really want to be precise, we could as well use boost::optional
> | or equivalent to define a type that describe the "object" it points
> | to: a char/inset code/paragraph end. What do you think?
>
> I do not quite understand

What do you expect from a PosIterator dereference? A char OR inset OR
paragraph end. So we can have a kind of union (but type-safer: I thought
that we can do something like this with boost::optional or some other
boost tool but I can be wrong).

> >> There is also a conceptual problem since PosIterator is both used as
> >> a iterator and as a container. Not really nice.
> |
> | Where?
>
> the asPosIterator function.
>
> I am trying to rewrite that so it does not require to be a friend.
> Friends often is the easy way out... completely by passes all access
> control.

Agreed, although is a small piece of code an so is easily auditable.
For LCursor we have exactly the same problem but is solved without
friendship (in lockPath, that does the work formerly done by asCursor)
because LCursor offers direct access to the container push function: this
is more dangerous IMO.

I still don't quite get why PosIterator is used as a container in that
function, but I agree that friends are bad in general.

Alfredo

the point with pimpls.

[Lars Gullik Bjønnes]

I know that I am the one who began introducing pimpls to lyx. After
that I have become quite wary of them... and feel more and more that
you should have a good reason to use them. 

This boils down to: (right now) What is the use of the pimpl in
ParIterator?

I have a patch where I remove it, get rid of asPosIterator, etc.
I think it is nice and it makes the code size smaller (should be
faster as well.)
This is with gcc 3.4 prerelease and cvs boost.

? 1
Index: BranchList.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BranchList.C,v
retrieving revision 1.10
diff -u -p -b -r1.10 BranchList.C
Index: PosIterator.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/PosIterator.C,v
retrieving revision 1.5
diff -u -p -b -r1.5 PosIterator.C
--- PosIterator.C	3 Dec 2003 18:17:15 -	1.5
+++ PosIterator.C	3 Jan 2004 14:18:14 -
@@ -26,6 +26,58 @@
 
 using boost::prior;
 
+
+PosIterator::PosIterator(ParagraphList * pl,
+			 ParagraphList::iterator pit,
+			 lyx::pos_type pos)
+{
+	stack_.push_back(PosIteratorItem(pl, pit, pos));
+}
+
+
+PosIterator::PosIterator(BufferView & bv)
+{
+	LyXText * text = bv.getLyXText();
+	lyx::pos_type pos = text->cursor.pos();
+	ParagraphList::iterator pit = text->cursorPar();
+
+	ParIterator par = bv.buffer()->par_iterator_begin();
+	ParIterator end = bv.buffer()->par_iterator_end();
+	for ( ; par != end; ++par) {
+		if (par.pit() == pit)
+			break;
+	}
+
+	setFrom(par, pos);
+}
+
+
+PosIterator::PosIterator(ParIterator const & par, lyx::pos_type pos)
+{
+	setFrom(par, pos);
+}
+
+
+void PosIterator::setFrom(ParIterator const & par, lyx::pos_type pos)
+{
+	BOOST_ASSERT(par.size() > 0);
+
+	ParIterator::PosHolder const & ph = par.positions();
+
+	int const last = par.size() - 1;
+	for (int i = 0; i < last; ++i) {
+		ParPosition const & pp = ph[i];
+		stack_.push_back(
+			PosIteratorItem(const_cast(pp.plist),
+	pp.pit, (*pp.it)->pos, *pp.index + 1));
+	}
+	ParPosition const & pp = ph[last];
+	stack_.push_back(
+		PosIteratorItem(const_cast(pp.plist), pp.pit, pos, 0));
+}
+
+
+
 PosIterator & PosIterator::operator++()
 {
 	BOOST_ASSERT(!stack_.empty());
@@ -95,15 +147,8 @@ PosIterator & PosIterator::operator--()
 }
 
 
-bool operator!=(PosIterator const & lhs, PosIterator const & rhs)
-{
-	return !(lhs == rhs);
-}
-
-
 bool operator==(PosIterator const & lhs, PosIterator const & rhs)
 {
-	
 	PosIteratorItem const & li = lhs.stack_.back();
 	PosIteratorItem const & ri = rhs.stack_.back();
 	
@@ -118,53 +163,10 @@ bool PosIterator::at_end() const
 }
 
 
-PosIterator::PosIterator(ParagraphList * pl, ParagraphList::iterator pit,
-			 lyx::pos_type pos)
-{
-	stack_.push_back(PosIteratorItem(pl, pit, pos));
-}
-
-
-PosIterator::PosIterator(BufferView & bv)
-{
-	LyXText * text = bv.getLyXText();
-	lyx::pos_type pos = text->cursor.pos();
-	ParagraphList::iterator pit = text->cursorPar();
-	
-	ParIterator par = bv.buffer()->par_iterator_begin();
-	ParIterator end = bv.buffer()->par_iterator_end();
-	for ( ; par != end; ++par) {
-		if (par.pit() == pit)
-			break;
-	}
-
-	operator=(par.asPosIterator(pos));
-}
-
-
 InsetOld * PosIterator::inset() const
 {
 	if (stack_.size() == 1)
 		return 0;
 	PosIteratorItem const & pi = stack_[stack_.size() - 2];
 	return pi.pit->getInset(pi.pos);
-}
-
-
-int distance(PosIterator const & cur, PosIterator const & end)
-{
-	PosIterator p = cur;
-	int count = 0;
-	for (; p != end; ++p, ++count)
-		;
-	return count;
-}
-
-
-void advance(PosIterator & cur, int howmuch)
-{
-	for (int i = 0; i < howmuch; ++i)
-		++cur;
-	for (int i = 0; i > howmuch; --i)
-		--cur;
 }
Index: PosIterator.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/PosIterator.h,v
retrieving revision 1.5
diff -u -p -b -r1.5 PosIterator.h
--- PosIterator.h	7 Nov 2003 09:40:48 -	1.5
+++ PosIterator.h	3 Jan 2004 14:18:14 -
@@ -36,14 +36,18 @@ struct PosIteratorItem 
 };
 
 
-class PosIterator
+class PosIterator : public std::iterator<
+	std::bidirectional_iterator_tag,
+	ParagraphList::value_type>
 {
 public:
+	// Creates a singular.
+	PosIterator() {};
+
 	PosIterator(BufferView & bv);
-	PosIterator(ParIterator & par, lyx::pos_type pos);
 	PosIterator(ParagraphList * pl, ParagraphList::iterator pit,
 		lyx::pos_type pos);
-	PosIterator(ParIterator const & parit, lyx::pos_type p);
+	PosIterator(ParIterator const & par, lyx::pos_type pos);
 	PosIterator & operator++();
 	PosIterator & operator--();
 	friend bool operator==(PosIterator const &, PosIterator const &);
@@ -52,20 +56,24 @@ public:
 	lyx::pos_type pos() const { return stack_.back().pos; }
 	bool at_end() const;
 	InsetOld * inset() const;
-	friend PosIterator ParIterator::asPosIterator(lyx::pos_type) const;
+//	friend PosIterator ParIterator::asPosIterator(lyx::pos_type) const;
 	friend 

kde-apps.org

[Juergen Spitzmueller]

FYI: I've added LyX to www.kde-apps.org, which seems to be the successor of 
the recently deceased apps.kde.com:
http://www.kde-apps.org/content/show.php?content=9811

Please feel free to suggest changes, screenshots etc.

Jürgen.

Re: QT-screen-fonts

[Lars Gullik Bjønnes]

Kornel Benko <[EMAIL PROTECTED]> writes:

| -BEGIN PGP SIGNED MESSAGE-
>
| Hi,
| I would like to have this patch in.
| The reason is:
| There is no such font family like "serif", "sans" or "monospace"
| in QT.
| Replacing them with "Times New Roman", "Arial" and "Courier"
| leads to a Version which does not crash and looks fine.

Are you confident that this will work on most QT installations?

-- 
Lgb

Re: QT-screen-fonts

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Samstag, 3. Januar 2004 17:53, Lars Gullik Bjønnes wrote:
> Kornel Benko <[EMAIL PROTECTED]> writes:
> 
> | -BEGIN PGP SIGNED MESSAGE-
> >
> | Hi,
> | I would like to have this patch in.
> | The reason is:
> | There is no such font family like "serif", "sans" or "monospace"
> | in QT.
> | Replacing them with "Times New Roman", "Arial" and "Courier"
> | leads to a Version which does not crash and looks fine.
> 
> Are you confident that this will work on most QT installations?

Unfortunatelly I am not :(. Being a non-expert on QT.

Sorry.
Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iQCVAwUBP/b5X7ewfbDGmeqhAQGAIgP8CMz9vFnRPGtNX5U++pDAU1/jmP8GMDcF
fDxgW0LB931zAp4uTz855vuzADqSD4+wA16rWdElZgRwvrf5D9IIu2kDAZL4yOGC
rA5/vaARve2KmjUQH7pZBp9wtTioQIK5ISchw1axaz43+VGJA0fggP399PT72f7c
p3Xxlp86VSA=
=SWV1
-END PGP SIGNATURE-

Re: QT-screen-fonts

[Lars Gullik Bjønnes]

Kornel Benko <[EMAIL PROTECTED]> writes:

| On Samstag, 3. Januar 2004 17:53, Lars Gullik Bjønnes wrote:
>> Kornel Benko <[EMAIL PROTECTED]> writes:
>> 
>> | -BEGIN PGP SIGNED MESSAGE-
>> >
>> | Hi,
>> | I would like to have this patch in.
>> | The reason is:
>> | There is no such font family like "serif", "sans" or "monospace"
>> | in QT.
>> | Replacing them with "Times New Roman", "Arial" and "Courier"
>> | leads to a Version which does not crash and looks fine.
>> 
>> Are you confident that this will work on most QT installations?
>
| Unfortunatelly I am not :(. Being a non-expert on QT.

Then we should investigate a bit before applying this.
Try to get some people on different systems to try your patch.

| Sorry.

no need for that.

-- 
Lgb

Re: Most wanted feature: Spell as you type

[Christian Ridderström]

Hi Janus

In order to not lose the thoughts in the mails, I put some notes here:

http://wiki.lyx.org/pmwiki.php/Devel/SpellCheckAsYouType

but I guess it needs a bit of structuring. And I might have missed 
important things etc. (I've only looked at teh mails in the user's list 
for instance).

The actual issue would probably benefit from a clearly defined suggestion 
of how the 'check as you type' mode should work,  and how it should be 
represented on the screen.

Then this suggestion could be discussed, to see what people think about 
it. Oh, and finally, an entry needs to be added to the bugzilla so that 
this isn't forgotten (unless a developer immediately starts working on 
this).

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr