Re: Bullets and qt an invisible relation. ;-)

[Jean-Marc Lasgouttes]

 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg Jose' Matos wrote:
 Can you fix it if that is the solution? I know nothing about Qt.

Georg Done. I don't know much more about qt, but I have learned that
Georg often a toqstr()/fromqstr() is needed. I do however not
Georg understand why this did compile on your machine and it did not
Georg on mine.

I think that Qt can be compiled with or without qstring/std::string
compatibility. Your Qt is probably different fro, the others'. And
this probably explains the crashes you got related to fonts...

JMarc

Re: Bullets and qt an invisible relation. ;-)

[Jean-Marc Lasgouttes]

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Jose' Matos wrote:
>> Can you fix it if that is the solution? I know nothing about Qt.

Georg> Done. I don't know much more about qt, but I have learned that
Georg> often a toqstr()/fromqstr() is needed. I do however not
Georg> understand why this did compile on your machine and it did not
Georg> on mine.

I think that Qt can be compiled with or without qstring/std::string
compatibility. Your Qt is probably different fro, the others'. And
this probably explains the crashes you got related to fonts...

JMarc

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

Jose' Matos wrote:

   Can you fix it if that is the solution? I know nothing about Qt.

Done. I don't know much more about qt, but I have learned that often a
toqstr()/fromqstr() is needed.
I do however not understand why this did compile on your machine and it did
not on mine.


Georg

Re: Bullets and qt an invisible relation. ;-)

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Jose' Matos wrote:

   Can you fix it if that is the solution? I know nothing about Qt.

| Done. I don't know much more about qt, but I have learned that often a
| toqstr()/fromqstr() is needed.
| I do however not understand why this did compile on your machine and it did
| not on mine.

He is probably using a newer qt than you?

-- 
Lgb

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Thursday 19 August 2004 07:32, Georg Baum wrote:

 Done. I don't know much more about qt, but I have learned that often a
 toqstr()/fromqstr() is needed.

  Thanks. :-)

 I do however not understand why this did compile on your machine and it
 did not on mine.

  Probably because I'm using qt 3.3.3 :-)

  Did you saw the recent changes that I made to lyx2lyx, do you have any 
comment? I'm thinking particularly about the LyX.py module.

  I intend to change the convert_1_4.lyx further, I will put both the 
convert and revert functions as cycles:

convertion_hub = ((223, (xyx, abc, def)),
  (224,(...),
  
  (235, (convert_bullets, add_begin_header, ...))

convert (file):
 for format, convert_list in convertion_hub:
  if file.format = format:
   continue
  for conv_step in convert_list:
   conv_step(file)
   -

  I think that after this change the code will be more readable. What do you 
think?

  I would like to have input from other developers using lyx2lyx, your 
feedback is appreciated. :-)

 Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

Jose' Matos wrote:

 On Thursday 19 August 2004 07:32, Georg Baum wrote:
 I do however not understand why this did compile on your machine and it
 did not on mine.
 
   Probably because I'm using qt 3.3.3 :-)

That may explain it. I have qt 3.2.1.

   Did you saw the recent changes that I made to lyx2lyx, do you have any
 comment? I'm thinking particularly about the LyX.py module.

I did notice them during cvs update, but I have had no chance to look at it
in more detail. Just one short comment: Splitting LyX.py from
parser_tools.py was a good change because the modules are smaller now, but
I think that it is not possible to remove all file format knowledge from
parser_tools. E.g. get_next_paragraph() would need to know the file format
version if we would use it for newer files.

   I intend to change the convert_1_4.lyx further, I will put both the
 convert and revert functions as cycles:
 
 convertion_hub = ((223, (xyx, abc, def)),
   (224,(...),
   
   (235, (convert_bullets, add_begin_header, ...))
 
 convert (file):
  for format, convert_list in convertion_hub:
   if file.format = format:
continue
   for conv_step in convert_list:
conv_step(file)
-
 
   I think that after this change the code will be more readable. What do
   you
 think?

I don't know how these cycles actually work, but I think I understand what
you are doing and yes, it is more readable.

   I would like to have input from other developers using lyx2lyx, your
 feedback is appreciated. :-)

I tend to only mention negative things, so no comment from me means either I
did not look or Well done! ;-)

BTW, the documentation of the file format changes in development/FORMAT is
missing.


Georg

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Thursday 19 August 2004 12:15, Georg Baum wrote:

Did you saw the recent changes that I made to lyx2lyx, do you have
  any comment? I'm thinking particularly about the LyX.py module.

 I did notice them during cvs update, but I have had no chance to look at
 it in more detail. Just one short comment: Splitting LyX.py from
 parser_tools.py was a good change because the modules are smaller now,
 but I think that it is not possible to remove all file format knowledge
 from parser_tools. E.g. get_next_paragraph() would need to know the file
 format version if we would use it for newer files.

  There are other functions who need to be reviewed after 1.4 release. We 
should probably change those functions that depend on previous versions to 
another file.

  This analysis was one of the reasons why I have place explicitly in the 
begin of each lyx_xxx.py the following line:

from parser_tools import 

  Notice that in the new versions we no longer call find_re, so I propose to 
pass some of them to an older_parser module.

I intend to change the convert_1_4.lyx further, I will put both the
  convert and revert functions as cycles:
 
  convertion_hub = ((223, (xyx, abc, def)),
(224,(...),

(235, (convert_bullets, add_begin_header, ...))
 
  convert (file):
   for format, convert_list in convertion_hub:
if file.format = format:
 continue
for conv_step in convert_list:
 conv_step(file)
 -
 
I think that after this change the code will be more readable. What
  do you
  think?

 I don't know how these cycles actually work, but I think I understand
 what you are doing and yes, it is more readable.

  Easier than it looks. :-)
  In python you can exchange the value of 2 variables doing this:

a, b = b, a

  this is an example of a tuple unrolling, so in the line

for format, convert_list in convertion_hub:

for the first item of this cycle this is the same as:

  format, convert_list = convertion_hub[0]

that is: format = 224 and convert_list = (xyx, abc, def)

  Does this makes sense now?

I would like to have input from other developers using lyx2lyx, your
  feedback is appreciated. :-)

 I tend to only mention negative things, so no comment from me means
 either I did not look or Well done! ;-)

  If you don't mind I take the second option. ;-)

 BTW, the documentation of the file format changes in development/FORMAT
 is missing.

  Oops, you got me. Done, thanks.

 Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Andre Poenitz]

On Tue, Aug 17, 2004 at 02:58:37PM +0100, John Levon wrote:
 On Tue, Aug 17, 2004 at 01:09:04PM +0100, Jose' Matos wrote:
 
If you click over it you get the initial dialog asking for a new custom 
  bullet. I am complayning that after adding a custom bullet the is no way 
  AFAIK to see its content.
 
 How on earth are we supposed to know what a custom bullet looks like?

Are you suggesting that LyX has no means to display e.g. \bullet properly?

Andre'

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

Jose' Matos wrote:

>   Can you fix it if that is the solution? I know nothing about Qt.

Done. I don't know much more about qt, but I have learned that often a
toqstr()/fromqstr() is needed.
I do however not understand why this did compile on your machine and it did
not on mine.


Georg

Re: Bullets and qt an invisible relation. ;-)

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Jose' Matos wrote:
>
>>   Can you fix it if that is the solution? I know nothing about Qt.
>
| Done. I don't know much more about qt, but I have learned that often a
| toqstr()/fromqstr() is needed.
| I do however not understand why this did compile on your machine and it did
| not on mine.

He is probably using a newer qt than you?

-- 
Lgb

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Thursday 19 August 2004 07:32, Georg Baum wrote:
>
> Done. I don't know much more about qt, but I have learned that often a
> toqstr()/fromqstr() is needed.

  Thanks. :-)

> I do however not understand why this did compile on your machine and it
> did not on mine.

  Probably because I'm using qt 3.3.3 :-)

  Did you saw the recent changes that I made to lyx2lyx, do you have any 
comment? I'm thinking particularly about the LyX.py module.

  I intend to change the convert_1_4.lyx further, I will put both the 
convert and revert functions as cycles:

convertion_hub = ((223, (xyx, abc, def)),
  (224,(...),
  
  (235, (convert_bullets, add_begin_header, ...))

convert (file):
 for format, convert_list in convertion_hub:
  if file.format >= format:
   continue
  for conv_step in convert_list:
   conv_step(file)
   -

  I think that after this change the code will be more readable. What do you 
think?

  I would like to have input from other developers using lyx2lyx, your 
feedback is appreciated. :-)

> Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

Jose' Matos wrote:

> On Thursday 19 August 2004 07:32, Georg Baum wrote:
>> I do however not understand why this did compile on your machine and it
>> did not on mine.
> 
>   Probably because I'm using qt 3.3.3 :-)

That may explain it. I have qt 3.2.1.

>   Did you saw the recent changes that I made to lyx2lyx, do you have any
> comment? I'm thinking particularly about the LyX.py module.

I did notice them during cvs update, but I have had no chance to look at it
in more detail. Just one short comment: Splitting LyX.py from
parser_tools.py was a good change because the modules are smaller now, but
I think that it is not possible to remove all file format knowledge from
parser_tools. E.g. get_next_paragraph() would need to know the file format
version if we would use it for newer files.

>   I intend to change the convert_1_4.lyx further, I will put both the
> convert and revert functions as cycles:
> 
> convertion_hub = ((223, (xyx, abc, def)),
>   (224,(...),
>   
>   (235, (convert_bullets, add_begin_header, ...))
> 
> convert (file):
>  for format, convert_list in convertion_hub:
>   if file.format >= format:
>continue
>   for conv_step in convert_list:
>conv_step(file)
>-
> 
>   I think that after this change the code will be more readable. What do
>   you
> think?

I don't know how these cycles actually work, but I think I understand what
you are doing and yes, it is more readable.

>   I would like to have input from other developers using lyx2lyx, your
> feedback is appreciated. :-)

I tend to only mention negative things, so no comment from me means either I
did not look or "Well done!" ;-)

BTW, the documentation of the file format changes in development/FORMAT is
missing.


Georg

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Thursday 19 August 2004 12:15, Georg Baum wrote:
>
> >   Did you saw the recent changes that I made to lyx2lyx, do you have
> > any comment? I'm thinking particularly about the LyX.py module.
>
> I did notice them during cvs update, but I have had no chance to look at
> it in more detail. Just one short comment: Splitting LyX.py from
> parser_tools.py was a good change because the modules are smaller now,
> but I think that it is not possible to remove all file format knowledge
> from parser_tools. E.g. get_next_paragraph() would need to know the file
> format version if we would use it for newer files.

  There are other functions who need to be reviewed after 1.4 release. We 
should probably change those functions that depend on previous versions to 
another file.

  This analysis was one of the reasons why I have place explicitly in the 
begin of each lyx_xxx.py the following line:

from parser_tools import 

  Notice that in the new versions we no longer call find_re, so I propose to 
pass some of them to an older_parser module.

> >   I intend to change the convert_1_4.lyx further, I will put both the
> > convert and revert functions as cycles:
> >
> > convertion_hub = ((223, (xyx, abc, def)),
> >   (224,(...),
> >   
> >   (235, (convert_bullets, add_begin_header, ...))
> >
> > convert (file):
> >  for format, convert_list in convertion_hub:
> >   if file.format >= format:
> >continue
> >   for conv_step in convert_list:
> >conv_step(file)
> >-
> >
> >   I think that after this change the code will be more readable. What
> > do you
> > think?
>
> I don't know how these cycles actually work, but I think I understand
> what you are doing and yes, it is more readable.

  Easier than it looks. :-)
  In python you can exchange the value of 2 variables doing this:

a, b = b, a

  this is an example of a tuple unrolling, so in the line

for format, convert_list in convertion_hub:

for the first item of this cycle this is the same as:

  format, convert_list = convertion_hub[0]

that is: format = 224 and convert_list = (xyx, abc, def)

  Does this makes sense now?

> >   I would like to have input from other developers using lyx2lyx, your
> > feedback is appreciated. :-)
>
> I tend to only mention negative things, so no comment from me means
> either I did not look or "Well done!" ;-)

  If you don't mind I take the second option. ;-)

> BTW, the documentation of the file format changes in development/FORMAT
> is missing.

  Oops, you got me. Done, thanks.

> Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Andre Poenitz]

On Tue, Aug 17, 2004 at 02:58:37PM +0100, John Levon wrote:
> On Tue, Aug 17, 2004 at 01:09:04PM +0100, Jose' Matos wrote:
> 
> >   If you click over it you get the initial dialog asking for a new custom 
> > bullet. I am complayning that after adding a custom bullet the is no way 
> > AFAIK to see its content.
> 
> How on earth are we supposed to know what a custom bullet looks like?

Are you suggesting that LyX has no means to display e.g. \bullet "properly"?

Andre'

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 18:21, John Levon wrote:
 On Tue, Aug 17, 2004 at 04:47:29PM +0100, Jose' Matos wrote:
But you know with lyx-qt 1.3, there the custom bullets are displayed
  instead of the ellipsis.
[...]

 Please apply that if it works

  Yes, it works. It is in my tree I will apply it soon. Thanks.

 john

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

John Levon wrote:

 diff -u -a -p -r1.22 BulletsModule.C
 --- BulletsModule.C 20 May 2004 09:36:27 -  1.22
 +++ BulletsModule.C 17 Aug 2004 17:21:01 -
 @@ -217,7 +217,7 @@ void BulletsModule::setBullet(QPushButto
  {
 if (b.getFont() == -1) {
 pb-setPixmap(QPixmap());
 -   pb-setText(...);
 +   pb-setText(b.getText());
 } else {
 pb-setPixmap(getPixmap(b.getFont(), b.getCharacter()));
 }

It does not compile here. I guess this should be
+   pb-setText(toqstr(b.getText()));
?

Georg

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Wed, Aug 18, 2004 at 05:36:25PM +0200, Georg Baum wrote:

 +   pb-setText(toqstr(b.getText()));

Yes

john

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Wednesday 18 August 2004 16:36, Georg Baum wrote:

 It does not compile here. I guess this should be
 +   pb-setText(toqstr(b.getText()));
 ?

  Can you fix it if that is the solution? I know nothing about Qt.
  Thanks.

 Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 18:21, John Levon wrote:
> On Tue, Aug 17, 2004 at 04:47:29PM +0100, Jose' Matos wrote:
> >   But you know with lyx-qt 1.3, there the custom bullets are displayed
> > instead of the ellipsis.
[...]
>
> Please apply that if it works

  Yes, it works. It is in my tree I will apply it soon. Thanks.

> john

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Georg Baum]

John Levon wrote:

> diff -u -a -p -r1.22 BulletsModule.C
> --- BulletsModule.C 20 May 2004 09:36:27 -  1.22
> +++ BulletsModule.C 17 Aug 2004 17:21:01 -
> @@ -217,7 +217,7 @@ void BulletsModule::setBullet(QPushButto
>  {
> if (b.getFont() == -1) {
> pb->setPixmap(QPixmap());
> -   pb->setText("...");
> +   pb->setText(b.getText());
> } else {
> pb->setPixmap(getPixmap(b.getFont(), b.getCharacter()));
> }

It does not compile here. I guess this should be
+   pb->setText(toqstr(b.getText()));
?

Georg

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Wed, Aug 18, 2004 at 05:36:25PM +0200, Georg Baum wrote:

> +   pb->setText(toqstr(b.getText()));

Yes

john

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Wednesday 18 August 2004 16:36, Georg Baum wrote:
>
> It does not compile here. I guess this should be
> +   pb->setText(toqstr(b.getText()));
> ?

  Can you fix it if that is the solution? I know nothing about Qt.
  Thanks.

> Georg

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 00:22, John Levon wrote:

 I do not understand your bug report.

 Are you referring to the fact that all the bullets in the Qt Document
 dialog are currently black-on-black for some reason?

  I will rephrase it then, if you want to add a custom bullet a dialog pops 
up to insert it. Then the qt frontend shows for the normal bullets its 
symbol (OK) but for custom it only shows 

  If you click over it you get the initial dialog asking for a new custom 
bullet. I am complayning that after adding a custom bullet the is no way 
AFAIK to see its content.

  Does this makes sense now?

 john

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Tue, Aug 17, 2004 at 01:09:04PM +0100, Jose' Matos wrote:

   If you click over it you get the initial dialog asking for a new custom 
 bullet. I am complayning that after adding a custom bullet the is no way 
 AFAIK to see its content.

How on earth are we supposed to know what a custom bullet looks like?

john

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 14:58, John Levon wrote:

 How on earth are we supposed to know what a custom bullet looks like?

  But you know with lyx-qt 1.3, there the custom bullets are displayed 
instead of the ellipsis.

  I send an attachement where you can compare the result for 1.3 and 1.4.

  In 1.4 you never see the values for the third and fourth levels, or am I 
missing something?

 john

-- 
José Abílio
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single 
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\bulletLaTeX 2
	
\end_bullet
\bulletLaTeX 3
	
\end_bullet

\layout Standard

\the_end

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Tue, Aug 17, 2004 at 04:47:29PM +0100, Jose' Matos wrote:

   But you know with lyx-qt 1.3, there the custom bullets are displayed 
 instead of the ellipsis.

diff -u -a -p -r1.22 BulletsModule.C
--- BulletsModule.C 20 May 2004 09:36:27 -  1.22
+++ BulletsModule.C 17 Aug 2004 17:21:01 -
@@ -217,7 +217,7 @@ void BulletsModule::setBullet(QPushButto
 {
if (b.getFont() == -1) {
pb-setPixmap(QPixmap());
-   pb-setText(...);
+   pb-setText(b.getText());
} else {
pb-setPixmap(getPixmap(b.getFont(), b.getCharacter()));
}


Please apply that if it works

john

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 00:22, John Levon wrote:
>
> I do not understand your bug report.
>
> Are you referring to the fact that all the bullets in the Qt Document
> dialog are currently black-on-black for some reason?

  I will rephrase it then, if you want to add a custom bullet a dialog pops 
up to insert it. Then the qt frontend shows for the normal bullets its 
symbol (OK) but for custom it only shows "...".

  If you click over it you get the initial dialog asking for a new custom 
bullet. I am complayning that after adding a custom bullet the is no way 
AFAIK to see its content.

  Does this makes sense now?

> john

-- 
José Abílio

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Tue, Aug 17, 2004 at 01:09:04PM +0100, Jose' Matos wrote:

>   If you click over it you get the initial dialog asking for a new custom 
> bullet. I am complayning that after adding a custom bullet the is no way 
> AFAIK to see its content.

How on earth are we supposed to know what a custom bullet looks like?

john

Re: Bullets and qt an invisible relation. ;-)

[Jose' Matos]

On Tuesday 17 August 2004 14:58, John Levon wrote:
>
> How on earth are we supposed to know what a custom bullet looks like?

  But you know with lyx-qt 1.3, there the custom bullets are displayed 
instead of the ellipsis.

  I send an attachement where you can compare the result for 1.3 and 1.4.

  In 1.4 you never see the values for the third and fourth levels, or am I 
missing something?

> john

-- 
José Abílio
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single 
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\bulletLaTeX 2
	""
\end_bullet
\bulletLaTeX 3
	""
\end_bullet

\layout Standard

\the_end

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Tue, Aug 17, 2004 at 04:47:29PM +0100, Jose' Matos wrote:

>   But you know with lyx-qt 1.3, there the custom bullets are displayed 
> instead of the ellipsis.

diff -u -a -p -r1.22 BulletsModule.C
--- BulletsModule.C 20 May 2004 09:36:27 -  1.22
+++ BulletsModule.C 17 Aug 2004 17:21:01 -
@@ -217,7 +217,7 @@ void BulletsModule::setBullet(QPushButto
 {
if (b.getFont() == -1) {
pb->setPixmap(QPixmap());
-   pb->setText("...");
+   pb->setText(b.getText());
} else {
pb->setPixmap(getPixmap(b.getFont(), b.getCharacter()));
}


Please apply that if it works

john

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Fri, Aug 13, 2004 at 11:21:15PM +0200, [EMAIL PROTECTED] wrote:

 Hi qt-friends,
   if we set a custom bullet in the qt-frontend
  there is no way to see it. In xforms we see the it in
 the bullet section of the document settings.

I do not understand your bug report.

Are you referring to the fact that all the bullets in the Qt Document
dialog are currently black-on-black for some reason?

john

Re: Bullets and qt an invisible relation. ;-)

[John Levon]

On Fri, Aug 13, 2004 at 11:21:15PM +0200, [EMAIL PROTECTED] wrote:

> Hi qt-friends,
>   if we set a custom bullet in the qt-frontend
>  there is no way to see it. In xforms we see the it in
> the bullet section of the document settings.

I do not understand your bug report.

Are you referring to the fact that all the bullets in the Qt Document
dialog are currently black-on-black for some reason?

john

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

 Can't we (ab)use mathed for the bullets? The validate() would come for

How?

 free, and we could store real strings as the parser is already there.

Hmmm... we have strings now.  It's just we choose to let the user have
free rein -- and what works now can be made to work in the Qt port
also (ready for a 1.3.0 release) and requires minimal changes (not
even a file format change as Edwin suggests).

If you want real strings all the time and to get rid of the \bullets
.lyx entries, leaving \bulletsLaTeX only, then that's a 1.4 thing IMO.

 The missing support for \ding is a matter of ten minutes...

Qt working the same as XForms would be less changes methinks.
It'd remove a lot of code too.


I've already described what the XForms dialog was supposed to allow
-- similar to what John wants to see also with depth button display of
appropriate bullet.  It seems a lot of rooting around to force output
into a string and then parse it back in again (especially if a user
may have made significant mods to the string) into a form that can
then be used to drive such a display.

I think both you and Edwin aren't realizing just what weird and
wonderful things can end up in user-modded string.  If you attempt to
parse such a thing how do you decide whether to set the size field or
leave the size in the string (maybe by saying the size must be the
first thing otherwise ignore it?).

If by parsing you mean you simply want to check if a bullet string
exists in the user string for validation (deciding which extra package
to include) then that would work okay but anything more complicated
than that and I think you're heading up the wrong path.  Even this
seems fraught with problems -- at least until I read your answer to
the How? question above.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
 On Wed, 13 Nov 2002, Andre Poenitz wrote:
 
  Can't we (ab)use mathed for the bullets? The validate() would come for
 
 How?

Don't know. I don't really know where and how the bullets are drawn...

 If you want real strings all the time and to get rid of the \bullets
 .lyx entries, leaving \bulletsLaTeX only, then that's a 1.4 thing IMO.

I think all of this is 1.4, except for the move of tempbullets from the
core...

  The missing support for \ding is a matter of ten minutes...
 
 Qt working the same as XForms would be less changes methinks.
 It'd remove a lot of code too.

Ok. So why don't do it that way for now?

 I think both you and Edwin aren't realizing just what weird and
 wonderful things can end up in user-modded string.  If you attempt to
 parse such a thing how do you decide whether to set the size field or
 leave the size in the string (maybe by saying the size must be the
 first thing otherwise ignore it?).

I never understood why this size thing is needed. 

In any case, \Large etc could be parsed as any other LaTeX command, so I
see no additional problem here.

 If by parsing you mean you simply want to check if a bullet string
 exists in the user string for validation (deciding which extra package
 to include) then that would work okay but anything more complicated
 than that and I think you're heading up the wrong path. 

No, by parsing I mean throwing it at the math parser. 

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
  Can't we (ab)use mathed for the bullets? The validate() would come for
 
 How?

With current CVS Bullet validation might be implemented as


#include mathed/math_data.h

Bullet::validate(LaTeXFeatures  features) const
{
asArray(text).validate(features);
}



Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

 On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
  On Wed, 13 Nov 2002, Andre Poenitz wrote:
 
   Can't we (ab)use mathed for the bullets? The validate() would come for
 
  How?

 Don't know. I don't really know where and how the bullets are drawn...

They aren't -- the pixmaps are in the dialog and that's it.  LaTeX
code is written.  Maybe one day we could use the previewer to render
the bullets and then show them in WYSIWYG, or just copy the pixmap
into the workarea would also do.
[...]
   The missing support for \ding is a matter of ten minutes...
 
  Qt working the same as XForms would be less changes methinks.
  It'd remove a lot of code too.

 Ok. So why don't do it that way for now?

I don't know.  I've wondering this myself.

  I think both you and Edwin aren't realizing just what weird and
  wonderful things can end up in user-modded string.  If you attempt to
  parse such a thing how do you decide whether to set the size field or
  leave the size in the string (maybe by saying the size must be the
  first thing otherwise ignore it?).

 I never understood why this size thing is needed.

So I can have big fat bullets or at least a size or two larger/smaller
as suits my taste and the need to be able to see them.  Some of
bullets look groovy but when placed in your text they look too small
(typically).

 In any case, \Large etc could be parsed as any other LaTeX command, so I
 see no additional problem here.

  If by parsing you mean you simply want to check if a bullet string
  exists in the user string for validation (deciding which extra package
  to include) then that would work okay but anything more complicated
  than that and I think you're heading up the wrong path.

 No, by parsing I mean throwing it at the math parser.

I'm still unsure what that gets us.  You know what the math parser
does.  I don't -- other than to guess it creates math insets which
Bullets are not (they aren't even insets).

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 06:32:08PM +1000, Allan Rae wrote:
 I'm still unsure what that gets us.  You know what the math parser
 does.  I don't -- other than to guess it creates math insets which
 Bullets are not (they aren't even insets).

It basically creates a MathArray, i.e. a some container. Whether you put
this into some inset or not is your choice.

If you happen to have a Painter object around, you could simply draw the
MathArray and throw it away.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

 On Wed, Nov 13, 2002 at 06:32:08PM +1000, Allan Rae wrote:
  I'm still unsure what that gets us.  You know what the math parser
  does.  I don't -- other than to guess it creates math insets which
  Bullets are not (they aren't even insets).

 It basically creates a MathArray, i.e. a some container. Whether you put
 this into some inset or not is your choice.

Ah, okay.  So it'd mainly be useful for validating and...

 If you happen to have a Painter object around, you could simply draw the
 MathArray and throw it away.

simple rendering.

Allan. (ARRae)  Time to go home now.

P.S. I may have time to look at temp_bullets - controller
tomorrow and maybe even make Qt port work in the standard manner if
someone hasn't got it doing that by then.

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 06:44:17PM +1000, Allan Rae wrote:
 P.S. I may have time to look at temp_bullets - controller
 tomorrow and maybe even make Qt port work in the standard manner if
 someone hasn't got it doing that by then.

Would be nice if you did that...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 QBrowseBox ... is there a good reason you didn't extend / base it on
 iconpalette.C ?

the reason I used it was that is was also used in klyx for the toolbars. on a 
toolbar button click it can popup wait for a click and dissapear. so  i guess 
i was anticipating on it to be used as well for the math and table toolbars. 
i also think that it looks better.

 What are the reasons we don't show the actual bullet chosen ?

None? ;-)

 I would like to see :

 o Level 1 |\ding57| [Choose...]
   x Level 2 |\ding38| [Choose...]
   * ...

 so it's immediately obvious.

Good idea

 Still not worth fixing now (there is plenty
 UI that could be improved in many dialogs, and it's not priority right
 now)

I agree

Ed.

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

> Can't we (ab)use mathed for the bullets? The validate() would come for

How?

> free, and we could store real strings as the parser is already there.

Hmmm... we have strings now.  It's just we choose to let the user have
free rein -- and what works now can be made to work in the Qt port
also (ready for a 1.3.0 release) and requires minimal changes (not
even a file format change as Edwin suggests).

If you want real strings all the time and to get rid of the \bullets
.lyx entries, leaving \bulletsLaTeX only, then that's a 1.4 thing IMO.

> The missing support for \ding is a matter of ten minutes...

Qt working the same as XForms would be less changes methinks.
It'd remove a lot of code too.


I've already described what the XForms dialog was supposed to allow
-- similar to what John wants to see also with depth button display of
appropriate bullet.  It seems a lot of rooting around to force output
into a string and then parse it back in again (especially if a user
may have made significant mods to the string) into a form that can
then be used to drive such a display.

I think both you and Edwin aren't realizing just what weird and
wonderful things can end up in user-modded string.  If you attempt to
parse such a thing how do you decide whether to set the size field or
leave the size in the string (maybe by saying the size must be the
first thing otherwise ignore it?).

If by parsing you mean you simply want to check if a bullet string
exists in the user string for validation (deciding which extra package
to include) then that would work okay but anything more complicated
than that and I think you're heading up the wrong path.  Even this
seems fraught with problems -- at least until I read your answer to
the "How?" question above.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
> On Wed, 13 Nov 2002, Andre Poenitz wrote:
> 
> > Can't we (ab)use mathed for the bullets? The validate() would come for
> 
> How?

Don't know. I don't really know where and how the bullets are drawn...

> If you want real strings all the time and to get rid of the \bullets
> .lyx entries, leaving \bulletsLaTeX only, then that's a 1.4 thing IMO.

I think all of this is 1.4, except for the move of tempbullets from the
core...

> > The missing support for \ding is a matter of ten minutes...
> 
> Qt working the same as XForms would be less changes methinks.
> It'd remove a lot of code too.

Ok. So why don't do it that way for now?

> I think both you and Edwin aren't realizing just what weird and
> wonderful things can end up in user-modded string.  If you attempt to
> parse such a thing how do you decide whether to set the size field or
> leave the size in the string (maybe by saying the size must be the
> first thing otherwise ignore it?).

I never understood why this size thing is needed. 

In any case, \Large etc could be parsed as any other LaTeX command, so I
see no additional problem here.

> If by parsing you mean you simply want to check if a bullet string
> exists in the user string for validation (deciding which extra package
> to include) then that would work okay but anything more complicated
> than that and I think you're heading up the wrong path. 

No, by "parsing" I mean "throwing it at the math parser". 

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
> > Can't we (ab)use mathed for the bullets? The validate() would come for
> 
> How?

With current CVS Bullet validation might be implemented as


#include "mathed/math_data.h"

Bullet::validate(LaTeXFeatures & features) const
{
asArray(text).validate(features);
}



Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

> On Wed, Nov 13, 2002 at 05:59:56PM +1000, Allan Rae wrote:
> > On Wed, 13 Nov 2002, Andre Poenitz wrote:
> >
> > > Can't we (ab)use mathed for the bullets? The validate() would come for
> >
> > How?
>
> Don't know. I don't really know where and how the bullets are drawn...

They aren't -- the pixmaps are in the dialog and that's it.  LaTeX
code is written.  Maybe one day we could use the previewer to render
the bullets and then show them in WYSIWYG, or just copy the pixmap
into the workarea would also do.
[...]
> > > The missing support for \ding is a matter of ten minutes...
> >
> > Qt working the same as XForms would be less changes methinks.
> > It'd remove a lot of code too.
>
> Ok. So why don't do it that way for now?

I don't know.  I've wondering this myself.

> > I think both you and Edwin aren't realizing just what weird and
> > wonderful things can end up in user-modded string.  If you attempt to
> > parse such a thing how do you decide whether to set the size field or
> > leave the size in the string (maybe by saying the size must be the
> > first thing otherwise ignore it?).
>
> I never understood why this size thing is needed.

So I can have big fat bullets or at least a size or two larger/smaller
as suits my taste and the need to be able to see them.  Some of
bullets look groovy but when placed in your text they look too small
(typically).

> In any case, \Large etc could be parsed as any other LaTeX command, so I
> see no additional problem here.
>
> > If by parsing you mean you simply want to check if a bullet string
> > exists in the user string for validation (deciding which extra package
> > to include) then that would work okay but anything more complicated
> > than that and I think you're heading up the wrong path.
>
> No, by "parsing" I mean "throwing it at the math parser".

I'm still unsure what that gets us.  You know what the math parser
does.  I don't -- other than to guess it creates math insets which
Bullets are not (they aren't even insets).

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 06:32:08PM +1000, Allan Rae wrote:
> I'm still unsure what that gets us.  You know what the math parser
> does.  I don't -- other than to guess it creates math insets which
> Bullets are not (they aren't even insets).

It basically creates a MathArray, i.e. a some container. Whether you put
this into some inset or not is your choice.

If you happen to have a Painter object around, you could simply draw the
MathArray and throw it away.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

> On Wed, Nov 13, 2002 at 06:32:08PM +1000, Allan Rae wrote:
> > I'm still unsure what that gets us.  You know what the math parser
> > does.  I don't -- other than to guess it creates math insets which
> > Bullets are not (they aren't even insets).
>
> It basically creates a MathArray, i.e. a some container. Whether you put
> this into some inset or not is your choice.

Ah, okay.  So it'd mainly be useful for validating and...

> If you happen to have a Painter object around, you could simply draw the
> MathArray and throw it away.

simple rendering.

Allan. (ARRae)  Time to go home now.

P.S. I may have time to look at temp_bullets -> controller
tomorrow and maybe even make Qt port work in the "standard" manner if
someone hasn't got it doing that by then.

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 06:44:17PM +1000, Allan Rae wrote:
> P.S. I may have time to look at temp_bullets -> controller
> tomorrow and maybe even make Qt port work in the "standard" manner if
> someone hasn't got it doing that by then.

Would be nice if you did that...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

> QBrowseBox ... is there a good reason you didn't extend / base it on
> iconpalette.C ?

the reason I used it was that is was also used in klyx for the toolbars. on a 
toolbar button click it can popup wait for a click and dissapear. so  i guess 
i was anticipating on it to be used as well for the math and table toolbars. 
i also think that it looks better.

> What are the reasons we don't show the actual bullet chosen ?

None? ;-)

> I would like to see :
>
> o Level 1 |\ding57| [Choose...]
>   x Level 2 |\ding38| [Choose...]
>   * ...
>
> so it's immediately obvious.

Good idea

> Still not worth fixing now (there is plenty
> UI that could be improved in many dialogs, and it's not priority right
> now)

I agree

Ed.

Re: bullets in qt

[Edwin Leuven]

On Tue Nov 12, 2002 05:22, Allan Rae wrote:
 The thing is the bullet tabs were always supposed to have the current
 bullet pushed for whatever level you were setting (ie. the
 pseudo-push-button was supposed to be indented but that never worked
 because of limitations in the image map thingy.

thing is the ui changed.

 A string is stored however for those cases where a person decides to
 customise the latex command -- such as wanting a rotated \ding{49}.

I was wondering btw why you didn't store the bullet as a string in general. 
what's the advantage of storing it as a font/char combination?

 All of them at once?

no

 Why couldn't you just request the string when the appropriate button
 is pushed?  That is, use a Bullet as a lookup table.

yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is 
private which means that I first need to set the bullet and then get the 
text. not very nice imho.

  I haven't looked
 at your code yet.  But I don't see why you need to change this -- even
 loading the pixmaps into the respective buttons on a bullets tab
 shouldn't have needed removing the strings. 

the pixmaps have got nothing to do with it.

Ed.

Re: bullets in qt

[Juergen Spitzmueller]

Edwin Leuven wrote:
 Applying bullets is still rotten though, so I won't apply for the moment.

Still problems with QBrowseBox? If so, then why not apply what you have (it's 
broken anyway), then I can probably have a look (note that I have not tested 
my patch from yesterday with your recent changes).

Jürgen.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 09:48:16AM +, Edwin Leuven wrote:
 I was wondering btw why you didn't store the bullet as a string in general. 
 what's the advantage of storing it as a font/char combination?

Probably no parser for the string exist(s|ed)...

Should be changed, though. Adds simplicity and flexibility...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 Still problems with QBrowseBox?

nope :-)

If so, then why not apply what you have
 (it's broken anyway), then I can probably have a look (note that I have not
 tested my patch from yesterday with your recent changes).

I'll apply then...

Re: bullets in qt

[Edwin Leuven]

On Tue Nov 12, 2002 08:54, Andre Poenitz wrote:
 On Tue, Nov 12, 2002 at 09:48:16AM +, Edwin Leuven wrote:
  I was wondering btw why you didn't store the bullet as a string in
  general. what's the advantage of storing it as a font/char combination?

 Probably no parser for the string exist(s|ed)...

 Should be changed, though. Adds simplicity and flexibility...

would make my life a bit simpler yes. although for the moment the bulletLaTeX 
doesn't preserve the size:

\bulletLaTeX 0
\(\alpha\)
\end_bullet

1st arg = level, 2nd = bullet, 3rd should be size (missing now).

This calls for a file format change I guess.

Ed.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 10:32:13AM +, Edwin Leuven wrote:
  Should be changed, though. Adds simplicity and flexibility...

I meant Should be changed - but not now.
 
 would make my life a bit simpler yes. although for the moment the bulletLaTeX 
 doesn't preserve the size:
 
 \bulletLaTeX 0
 \(\alpha\)
 \end_bullet
 
 1st arg = level, 2nd = bullet, 3rd should be size (missing now).
 
 This calls for a file format change I guess.

Why exactly do we need the size?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

Allan,

What are these for in bufferparams?

boost::arrayBullet, 4 temp_bullets;

Sorry if I am being thick.

Thanks, Ed.

Re: bullets in qt

[Edwin Leuven]

I can preview newfile9 but not newfile10. Does anyone know what is wrong here?

Thanks, Ed.
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass amsart-seq
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing onehalf 
\papersize a4paper
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle plain
\bulletLaTeX 0
	\(\clubsuit\)
\end_bullet
\bulletLaTeX 1
	\(\bullet\)
\end_bullet
\bulletLaTeX 2
	\ding{118}
\end_bullet
\bulletLaTeX 3
	\ding{57}
\end_bullet

\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\the_end

#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass amsart-seq
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing onehalf 
\papersize a4paper
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle plain
\bulletLaTeX 0
	\(\alpha\)
\end_bullet
\bulletLaTeX 1
	\normalfont\bfseries{-}
\end_bullet
\bulletLaTeX 2
	\(\beta\)
\end_bullet
\bulletLaTeX 3
	\(\gamma\)
\end_bullet

\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\the_end

Re: bullets in qt

[Edwin Leuven]

I've commited the stuff I had. Remaining issue is the one below...

On Tue Nov 12, 2002 10:57, Edwin Leuven wrote:
 I can preview newfile9 but not newfile10. Does anyone know what is wrong
 here?

 Thanks, Ed.

Re: bullets in qt

[Juergen Spitzmueller]

Am Dienstag, 12. November 2002 11:57 schrieb Edwin Leuven:
 I can preview newfile9 but not newfile10. Does anyone know what is wrong
 here?

\usepackage{pifont} 
(for \ding{118}) is missing in the preamble. XForms' dialog inserts it.

Jürgen.

Re: bullets in qt

[Edwin Leuven]

  I can preview newfile9 but not newfile10. Does anyone know what is wrong
  here?

 \usepackage{pifont}
 (for \ding{118}) is missing in the preamble.
ah!

 XForms' dialog inserts it.

no it doesn't. these bullets are usually not saved as strings. at the moment 
qt saves them as strings. if we want do so we need to make sure that the 
necessary packages are added/removed to/from the preamble.

packages are handled in buffer.C:

// the bullet shapes are buffer level not paragraph level
// so they are tested here
for (int i = 0; i  4; ++i) {
if (params.user_defined_bullets[i] != ITEMIZE_DEFAULTS[i]) {
 int const font = params.user_defined_bullets[i].getFont();
if (font == 0) {
int const c = params
.user_defined_bullets[i]
.getCharacter();
if (c == 16
   || c == 17
   || c == 25
   || c == 26
   || c == 31) { 
   features.require(latexsym); }
} else if (font == 1) {
features.require(amssymb);
} else if ((font = 2  font = 5)) {
features.require(pifont);
}
}
}


sigh

thanks, Ed.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 11:47:59AM +, Edwin Leuven wrote:
 sigh

Indeed.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[John Levon]

On Mon, Nov 11, 2002 at 01:14:26AM +0100, Edwin Leuven wrote:

 For some reason QBrowseBox doesn't get mouse focus. It does when one hold the 

QBrowseBox ... is there a good reason you didn't extend / base it on
iconpalette.C ?

 I need to set the bullet codes. for now I have put them in the new files 

What are the reasons we don't show the actual bullet chosen ?

I would like to see :

o Level 1 |\ding57| [Choose...]
x Level 2 |\ding38| [Choose...]
* ...

so it's immediately obvious. Still not worth fixing now (there is plenty
UI that could be improved in many dialogs, and it's not priority right
now)

regards
john


-- 
Khendon's Law: If the same point is made twice by the same person,
the thread is over.

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

 On Tue Nov 12, 2002 05:22, Allan Rae wrote:
  The thing is the bullet tabs were always supposed to have the current
  bullet pushed for whatever level you were setting (ie. the
  pseudo-push-button was supposed to be indented but that never worked
  because of limitations in the image map thingy.

 thing is the ui changed.

So now the appropriate bullet will be highlighted/pushed/whatever?
Hmmm... doesn't seem to be.

One other thing I wanted to have but never succeeded in getting to
work¹ was to have the four bullet depth buttons actually display the
appropriate bullet pixmap (ignoring rotations or resizes -- any custom
string would have gotten a Custom label instead of a pixmap)

¹ The best I got was a segfault and Alejandro had a go at fixing my
code but still got segfaults so we gave up and just labelled the
buttons instead.  The problem was writing something like what bitBlt()
does in QBrowseBox.

  A string is stored however for those cases where a person decides to
  customise the latex command -- such as wanting a rotated \ding{49}.

 I was wondering btw why you didn't store the bullet as a string in general.
 what's the advantage of storing it as a font/char combination?

It was generally simpler to figure out what additional packages needed
to be loaded and meant I didn't need to write a parser (or at least a
scanner that searched for a string match in the table of bullets).

It also kept a clear distinction between customised bullets (where the
text field has been edited) and a known bullet.  It also means that
the text in the text field is always correct -- it shows the size and
the bullet; if a user decides to edit the field then they are entirely
responsible for the result.  This way they can choose a basic form for
the string, say \Large\(\star\) and then decide to put it in a
\raisebox{} so it looks right to them giving
\raisebox{-2pt}{\Large\(\star\)}.  Using your method they end up
writing \raisebox{-2pt}{\(\star\)} and have a \Large prepended.
This separation of some of the information looks confusing to me even
if it does give the same result in this case.

BTW, the two formats for writing bullets in lyx files are:

\bulletLaTeX 0
\Large\(\bullet\)
\end_bullet

and

\bullet 0
0
8
6
\end_bullet

It so happens the above two are equivalent it's just that the first
entry was hand editted.  In your case where you want to write strings
you can use the first format -- you'll just have to parse the size as
well.  After all if you want to write strings you must either have a
parser or a custom bullet string.  The second format (actually the
primary format) just shows:

\bullet level
panel   (0 = standard and so on)
offset
size(standard latex sizes with 0 = \tiny)
\end_bullet


Anyway, we all know I'm into bad UI but in this case I still think my
way is better.  Besides you have all the info you need to support both
existing formats.

  Why couldn't you just request the string when the appropriate button
  is pushed?  That is, use a Bullet as a lookup table.

 yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is
 private which means that I first need to set the bullet and then get the
 text. not very nice imho.

Instead of having src/frontends/qt2/bulletstrings.[Ch] create a
singleton that is used by both frontends (removing the tables from
Bullet.[Ch]) and use that for lookup of strings.  Then such functions
as:

void BulletsModule::standard(int row, int col)
{
le_-setText(bullets_standard[6*row + col]);
}

would look like:

void BulletsModule::standard(int row, int col)
{
le_-setText(bullet_strings.get(standard, 6*row + col));
}

or similar and the Bullets.C code would also use that.

And while I'm at it I'd prefer to see:

void BulletsModule::standard(int row, int col)
{
le_-setText(size_strings.get(size) +
 bullet_strings.get(standard, 6*row + col));
}


 the pixmaps have got nothing to do with it.

I was thinking you might have been wanting to iterate through the
table to construct the name of the next pixmap to load into the
next button in the GUI -- but I see now you do this in a manner
similar to XForms frontend.

Allan. (ARRae)

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

   I can preview newfile9 but not newfile10. Does anyone know what is wrong
   here?
 
  \usepackage{pifont}
  (for \ding{118}) is missing in the preamble.
 ah!

  XForms' dialog inserts it.

 no it doesn't. these bullets are usually not saved as strings. at the moment
 qt saves them as strings. if we want do so we need to make sure that the
 necessary packages are added/removed to/from the preamble.

 packages are handled in buffer.C:

 // the bullet shapes are buffer level not paragraph level
 // so they are tested here
 for (int i = 0; i  4; ++i) {
 if (params.user_defined_bullets[i] != ITEMIZE_DEFAULTS[i]) {
  int const font = params.user_defined_bullets[i].getFont();
 if (font == 0) {
 int const c = params
 .user_defined_bullets[i]
 .getCharacter();
 if (c == 16
|| c == 17
|| c == 25
|| c == 26
|| c == 31) {
features.require(latexsym);
 }
 } else if (font == 1) {
 features.require(amssymb);
 } else if ((font = 2  font = 5)) {
 features.require(pifont);
 }
 }
 }


 sigh

Indeed there are 216 bullets and while the majority of these are
either dingbats from the pifont package or available by default from
latex there are a number of other symbols that were collected from
different packages.  The closest I could get to a reasonable lowest
common denominator was 36 and that meant putting two sets of symbols
together: the standard ones from either text or math and the handful
from the latexsym package.

Package checking has to be done somewhere, somehow.  Maybe an
additional parameter or three could be placed in params to say whether
pifont, amssymb, latexsym needs to be included -- now that we have
controllers the above code could be moved there and modified to suit a
better scheme.  It would probably be better to have the controller
name the packages required so that validate() just iterates over a
string.

Either way, just hoping that a string naming which bullet a user wants
isn't going to work unless you complicate the input handling by doing
the checking there.

Allan. (ARRae)

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

 Allan,

 What are these for in bufferparams?

 boost::arrayBullet, 4 temp_bullets;

 Sorry if I am being thick.

They are used as temporary storage by the GUI frontend -- well XForms
anyway as seen here:

void FormDocument::ChoiceBulletSize(FL_OBJECT * ob, long /*data*/)
{
BufferParams  param = lv_.buffer()-params;

// convert from 1-6 range to -1-4
param.temp_bullets[current_bullet_depth].setSize(fl_get_choice(ob) - 2);
fl_set_input(bullets_-input_bullet_latex,
 param.temp_bullets[current_bullet_depth].getText().c_str());
}


So this also answers your previous comment:

 yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is
 private which means that I first need to set the bullet and then get the
 text. not very nice imho.

It's what is already done.  The temporary variables could have been
kept in the dialog implementation but by keeping them in the buffer
params when you switch buffers you got (past tense because it looks
like someone has changed it) what you were editing -- allowing you to
switch back and forth between buffers but keep the state of the dialog
the same upon return to the previous buffer.

Then the temp_bullets are copied to the real bullet settings when the
user applies or okays the dialog.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 01:22:53PM +1000, Allan Rae wrote:
 It's what is already done.  The temporary variables could have been
 kept in the dialog implementation but by keeping them in the buffer
 params when you switch buffers you got (past tense because it looks
 like someone has changed it) what you were editing -- allowing you to
 switch back and forth between buffers but keep the state of the dialog
 the same upon return to the previous buffer.

Is that such an important feature to justify putting ui helper stuff into
bufferparams?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 01:00:48PM +1000, Allan Rae wrote:
 Indeed there are 216 bullets and while the majority of these are
 either dingbats from the pifont package or available by default from
 latex there are a number of other symbols that were collected from
 different packages.  The closest I could get to a reasonable lowest
 common denominator was 36 and that meant putting two sets of symbols
 together: the standard ones from either text or math and the handful
 from the latexsym package.
 
 Package checking has to be done somewhere, somehow.  Maybe an
 additional parameter or three could be placed in params to say whether
 pifont, amssymb, latexsym needs to be included -- now that we have
 controllers the above code could be moved there and modified to suit a
 better scheme.  It would probably be better to have the controller
 name the packages required so that validate() just iterates over a
 string.

Can't we (ab)use mathed for the bullets? The validate() would come for
free, and we could store real strings as the parser is already there.
The missing support for \ding is a matter of ten minutes...

Andre'

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

 On Wed, Nov 13, 2002 at 01:22:53PM +1000, Allan Rae wrote:
  It's what is already done.  The temporary variables could have been
  kept in the dialog implementation but by keeping them in the buffer
  params when you switch buffers you got (past tense because it looks
  like someone has changed it) what you were editing -- allowing you to
  switch back and forth between buffers but keep the state of the dialog
  the same upon return to the previous buffer.

 Is that such an important feature to justify putting ui helper stuff into
 bufferparams?

No, and it should be different anyway if we wanted to ensure
everything in the dialog was saved between buffer switches -- we
should have a temp_params in the dialog code.

Or as a minimal tweak move the params.temp_bullets to the
dialog/controller.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:37:48PM +1000, Allan Rae wrote:
 Or as a minimal tweak move the params.temp_bullets to the
 dialog/controller.

This sounds ok to me.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

On Tue Nov 12, 2002 05:22, Allan Rae wrote:
> The thing is the bullet tabs were always supposed to have the current
> bullet "pushed" for whatever level you were setting (ie. the
> pseudo-push-button was supposed to be indented but that never worked
> because of limitations in the image map thingy.

thing is the ui changed.

> A string is stored however for those cases where a person decides to
> customise the latex command -- such as wanting a rotated \ding{49}.

I was wondering btw why you didn't store the bullet as a string in general. 
what's the advantage of storing it as a font/char combination?

> All of them at once?

no

> Why couldn't you just request the string when the appropriate button
> is pushed?  That is, use a Bullet as a lookup table.

yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is 
private which means that I first need to set the bullet and then get the 
text. not very nice imho.

>  I haven't looked
> at your code yet.  But I don't see why you need to change this -- even
> loading the pixmaps into the respective buttons on a bullets tab
> shouldn't have needed removing the strings. 

the pixmaps have got nothing to do with it.

Ed.

Re: bullets in qt

[Juergen Spitzmueller]

Edwin Leuven wrote:
> Applying bullets is still rotten though, so I won't apply for the moment.

Still problems with QBrowseBox? If so, then why not apply what you have (it's 
broken anyway), then I can probably have a look (note that I have not tested 
my patch from yesterday with your recent changes).

Jürgen.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 09:48:16AM +, Edwin Leuven wrote:
> I was wondering btw why you didn't store the bullet as a string in general. 
> what's the advantage of storing it as a font/char combination?

Probably no parser for the string exist(s|ed)...

Should be changed, though. Adds simplicity and flexibility...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

> Still problems with QBrowseBox?

nope :-)

>If so, then why not apply what you have
> (it's broken anyway), then I can probably have a look (note that I have not
> tested my patch from yesterday with your recent changes).

I'll apply then...

Re: bullets in qt

[Edwin Leuven]

On Tue Nov 12, 2002 08:54, Andre Poenitz wrote:
> On Tue, Nov 12, 2002 at 09:48:16AM +, Edwin Leuven wrote:
> > I was wondering btw why you didn't store the bullet as a string in
> > general. what's the advantage of storing it as a font/char combination?
>
> Probably no parser for the string exist(s|ed)...
>
> Should be changed, though. Adds simplicity and flexibility...

would make my life a bit simpler yes. although for the moment the bulletLaTeX 
doesn't preserve the size:

\bulletLaTeX 0
"\(\alpha\)"
\end_bullet

1st arg = level, 2nd = bullet, 3rd should be size (missing now).

This calls for a file format change I guess.

Ed.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 10:32:13AM +, Edwin Leuven wrote:
> > Should be changed, though. Adds simplicity and flexibility...

I meant "Should be changed - but not now".
 
> would make my life a bit simpler yes. although for the moment the bulletLaTeX 
> doesn't preserve the size:
> 
> \bulletLaTeX 0
> "\(\alpha\)"
> \end_bullet
> 
> 1st arg = level, 2nd = bullet, 3rd should be size (missing now).
> 
> This calls for a file format change I guess.

Why exactly do we need the size?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

Allan,

What are these for in bufferparams?

boost::array temp_bullets;

Sorry if I am being thick.

Thanks, Ed.

Re: bullets in qt

[Edwin Leuven]

I can preview newfile9 but not newfile10. Does anyone know what is wrong here?

Thanks, Ed.
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass amsart-seq
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing onehalf 
\papersize a4paper
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle plain
\bulletLaTeX 0
	"\(\clubsuit\)"
\end_bullet
\bulletLaTeX 1
	"\(\bullet\)"
\end_bullet
\bulletLaTeX 2
	"\ding{118}"
\end_bullet
\bulletLaTeX 3
	"\ding{57}"
\end_bullet

\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\the_end

#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass amsart-seq
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize 11
\spacing onehalf 
\papersize a4paper
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle plain
\bulletLaTeX 0
	"\(\alpha\)"
\end_bullet
\bulletLaTeX 1
	"\normalfont\bfseries{-}"
\end_bullet
\bulletLaTeX 2
	"\(\beta\)"
\end_bullet
\bulletLaTeX 3
	"\(\gamma\)"
\end_bullet

\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\begin_deeper 
\layout Itemize

s
\the_end

Re: bullets in qt

[Edwin Leuven]

I've commited the stuff I had. Remaining issue is the one below...

On Tue Nov 12, 2002 10:57, Edwin Leuven wrote:
> I can preview newfile9 but not newfile10. Does anyone know what is wrong
> here?
>
> Thanks, Ed.

Re: bullets in qt

[Juergen Spitzmueller]

Am Dienstag, 12. November 2002 11:57 schrieb Edwin Leuven:
> I can preview newfile9 but not newfile10. Does anyone know what is wrong
> here?

\usepackage{pifont} 
(for \ding{118}) is missing in the preamble. XForms' dialog inserts it.

Jürgen.

Re: bullets in qt

[Edwin Leuven]

> > I can preview newfile9 but not newfile10. Does anyone know what is wrong
> > here?
>
> \usepackage{pifont}
> (for \ding{118}) is missing in the preamble.
ah!

> XForms' dialog inserts it.

no it doesn't. these bullets are usually not saved as strings. at the moment 
qt saves them as strings. if we want do so we need to make sure that the 
necessary packages are added/removed to/from the preamble.

packages are handled in buffer.C:

// the bullet shapes are buffer level not paragraph level
// so they are tested here
for (int i = 0; i < 4; ++i) {
if (params.user_defined_bullets[i] != ITEMIZE_DEFAULTS[i]) {
 int const font = params.user_defined_bullets[i].getFont();
if (font == 0) {
int const c = params
.user_defined_bullets[i]
.getCharacter();
if (c == 16
   || c == 17
   || c == 25
   || c == 26
   || c == 31) { 
   features.require("latexsym"); }
} else if (font == 1) {
features.require("amssymb");
} else if ((font >= 2 && font <= 5)) {
features.require("pifont");
}
}
}




thanks, Ed.

Re: bullets in qt

[Andre Poenitz]

On Tue, Nov 12, 2002 at 11:47:59AM +, Edwin Leuven wrote:
> 

Indeed.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[John Levon]

On Mon, Nov 11, 2002 at 01:14:26AM +0100, Edwin Leuven wrote:

> For some reason QBrowseBox doesn't get mouse focus. It does when one hold the 

QBrowseBox ... is there a good reason you didn't extend / base it on
iconpalette.C ?

> I need to set the bullet codes. for now I have put them in the new files 

What are the reasons we don't show the actual bullet chosen ?

I would like to see :

o Level 1 |\ding57| [Choose...]
x Level 2 |\ding38| [Choose...]
* ...

so it's immediately obvious. Still not worth fixing now (there is plenty
UI that could be improved in many dialogs, and it's not priority right
now)

regards
john


-- 
Khendon's Law: If the same point is made twice by the same person,
the thread is over.

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

> On Tue Nov 12, 2002 05:22, Allan Rae wrote:
> > The thing is the bullet tabs were always supposed to have the current
> > bullet "pushed" for whatever level you were setting (ie. the
> > pseudo-push-button was supposed to be indented but that never worked
> > because of limitations in the image map thingy.
>
> thing is the ui changed.

So now the appropriate bullet will be highlighted/pushed/whatever?
Hmmm... doesn't seem to be.

One other thing I wanted to have but never succeeded in getting to
work¹ was to have the four bullet depth buttons actually display the
appropriate bullet pixmap (ignoring rotations or resizes -- any custom
string would have gotten a "Custom" label instead of a pixmap)

¹ The best I got was a segfault and Alejandro had a go at fixing my
code but still got segfaults so we gave up and just labelled the
buttons instead.  The problem was writing something like what bitBlt()
does in QBrowseBox.

> > A string is stored however for those cases where a person decides to
> > customise the latex command -- such as wanting a rotated \ding{49}.
>
> I was wondering btw why you didn't store the bullet as a string in general.
> what's the advantage of storing it as a font/char combination?

It was generally simpler to figure out what additional packages needed
to be loaded and meant I didn't need to write a parser (or at least a
scanner that searched for a string match in the table of bullets).

It also kept a clear distinction between customised bullets (where the
text field has been edited) and a known bullet.  It also means that
the text in the text field is always correct -- it shows the size and
the bullet; if a user decides to edit the field then they are entirely
responsible for the result.  This way they can choose a basic form for
the string, say "\Large\(\star\)" and then decide to put it in a
\raisebox{} so it looks right to them giving
"\raisebox{-2pt}{\Large\(\star\)}".  Using your method they end up
writing "\raisebox{-2pt}{\(\star\)}" and have a \Large prepended.
This separation of some of the information looks confusing to me even
if it does give the same result in this case.

BTW, the two formats for writing bullets in lyx files are:

\bulletLaTeX 0
"\Large\(\bullet\)"
\end_bullet

and

\bullet 0
0
8
6
\end_bullet

It so happens the above two are equivalent it's just that the first
entry was hand editted.  In your case where you want to write strings
you can use the first format -- you'll just have to parse the size as
well.  After all if you want to write strings you must either have a
parser or a custom bullet string.  The second format (actually the
primary format) just shows:

\bullet level
panel   (0 = standard and so on)
offset
size(standard latex sizes with 0 = \tiny)
\end_bullet


Anyway, we all know I'm into bad UI but in this case I still think my
way is better.  Besides you have all the info you need to support both
existing formats.

> > Why couldn't you just request the string when the appropriate button
> > is pushed?  That is, use a Bullet as a lookup table.
>
> yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is
> private which means that I first need to set the bullet and then get the
> text. not very nice imho.

Instead of having src/frontends/qt2/bulletstrings.[Ch] create a
singleton that is used by both frontends (removing the tables from
Bullet.[Ch]) and use that for lookup of strings.  Then such functions
as:

void BulletsModule::standard(int row, int col)
{
le_->setText(bullets_standard[6*row + col]);
}

would look like:

void BulletsModule::standard(int row, int col)
{
le_->setText(bullet_strings.get("standard", 6*row + col));
}

or similar and the Bullets.C code would also use that.

And while I'm at it I'd prefer to see:

void BulletsModule::standard(int row, int col)
{
le_->setText(size_strings.get(size) +
 bullet_strings.get("standard", 6*row + col));
}


> the pixmaps have got nothing to do with it.

I was thinking you might have been wanting to iterate through the
table to construct the name of the next pixmap to load into the
next button in the GUI -- but I see now you do this in a manner
similar to XForms frontend.

Allan. (ARRae)

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

> > > I can preview newfile9 but not newfile10. Does anyone know what is wrong
> > > here?
> >
> > \usepackage{pifont}
> > (for \ding{118}) is missing in the preamble.
> ah!
>
> > XForms' dialog inserts it.
>
> no it doesn't. these bullets are usually not saved as strings. at the moment
> qt saves them as strings. if we want do so we need to make sure that the
> necessary packages are added/removed to/from the preamble.
>
> packages are handled in buffer.C:
>
> // the bullet shapes are buffer level not paragraph level
> // so they are tested here
> for (int i = 0; i < 4; ++i) {
> if (params.user_defined_bullets[i] != ITEMIZE_DEFAULTS[i]) {
>  int const font = params.user_defined_bullets[i].getFont();
> if (font == 0) {
> int const c = params
> .user_defined_bullets[i]
> .getCharacter();
> if (c == 16
>|| c == 17
>|| c == 25
>|| c == 26
>|| c == 31) {
>features.require("latexsym");
> }
> } else if (font == 1) {
> features.require("amssymb");
> } else if ((font >= 2 && font <= 5)) {
> features.require("pifont");
> }
> }
> }
>
>
> 

Indeed there are 216 bullets and while the majority of these are
either dingbats from the pifont package or available by default from
latex there are a number of other symbols that were collected from
different packages.  The closest I could get to a reasonable lowest
common denominator was 36 and that meant putting two sets of symbols
together: the "standard" ones from either text or math and the handful
from the latexsym package.

Package checking has to be done somewhere, somehow.  Maybe an
additional parameter or three could be placed in params to say whether
pifont, amssymb, latexsym needs to be included -- now that we have
controllers the above code could be moved there and modified to suit a
better scheme.  It would probably be better to have the controller
name the packages required so that validate() just iterates over a
string.

Either way, just hoping that a string naming which bullet a user wants
isn't going to work unless you complicate the input handling by doing
the checking there.

Allan. (ARRae)

Re: bullets in qt

[Allan Rae]

On Tue, 12 Nov 2002, Edwin Leuven wrote:

> Allan,
>
> What are these for in bufferparams?
>
> boost::array temp_bullets;
>
> Sorry if I am being thick.

They are used as temporary storage by the GUI frontend -- well XForms
anyway as seen here:

void FormDocument::ChoiceBulletSize(FL_OBJECT * ob, long /*data*/)
{
BufferParams & param = lv_.buffer()->params;

// convert from 1-6 range to -1-4
param.temp_bullets[current_bullet_depth].setSize(fl_get_choice(ob) - 2);
fl_set_input(bullets_->input_bullet_latex,
 param.temp_bullets[current_bullet_depth].getText().c_str());
}


So this also answers your previous comment:

> yes, perhaps I should store a Bullet for this but bulletEntry(int f, int c) is
> private which means that I first need to set the bullet and then get the
> text. not very nice imho.

It's what is already done.  The temporary variables could have been
kept in the dialog implementation but by keeping them in the buffer
params when you switch buffers you got (past tense because it looks
like someone has changed it) what you were editing -- allowing you to
switch back and forth between buffers but keep the state of the dialog
the same upon return to the previous buffer.

Then the temp_bullets are copied to the real bullet settings when the
user applies or okays the dialog.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 01:22:53PM +1000, Allan Rae wrote:
> It's what is already done.  The temporary variables could have been
> kept in the dialog implementation but by keeping them in the buffer
> params when you switch buffers you got (past tense because it looks
> like someone has changed it) what you were editing -- allowing you to
> switch back and forth between buffers but keep the state of the dialog
> the same upon return to the previous buffer.

Is that such an important feature to justify putting ui helper stuff into
bufferparams?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 01:00:48PM +1000, Allan Rae wrote:
> Indeed there are 216 bullets and while the majority of these are
> either dingbats from the pifont package or available by default from
> latex there are a number of other symbols that were collected from
> different packages.  The closest I could get to a reasonable lowest
> common denominator was 36 and that meant putting two sets of symbols
> together: the "standard" ones from either text or math and the handful
> from the latexsym package.
> 
> Package checking has to be done somewhere, somehow.  Maybe an
> additional parameter or three could be placed in params to say whether
> pifont, amssymb, latexsym needs to be included -- now that we have
> controllers the above code could be moved there and modified to suit a
> better scheme.  It would probably be better to have the controller
> name the packages required so that validate() just iterates over a
> string.

Can't we (ab)use mathed for the bullets? The validate() would come for
free, and we could store real strings as the parser is already there.
The missing support for \ding is a matter of ten minutes...

Andre'

Re: bullets in qt

[Allan Rae]

On Wed, 13 Nov 2002, Andre Poenitz wrote:

> On Wed, Nov 13, 2002 at 01:22:53PM +1000, Allan Rae wrote:
> > It's what is already done.  The temporary variables could have been
> > kept in the dialog implementation but by keeping them in the buffer
> > params when you switch buffers you got (past tense because it looks
> > like someone has changed it) what you were editing -- allowing you to
> > switch back and forth between buffers but keep the state of the dialog
> > the same upon return to the previous buffer.
>
> Is that such an important feature to justify putting ui helper stuff into
> bufferparams?

No, and it should be different anyway if we wanted to ensure
everything in the dialog was saved between buffer switches -- we
should have a temp_params in the dialog code.

Or as a minimal tweak move the params.temp_bullets to the
dialog/controller.

Allan. (ARRae)

Re: bullets in qt

[Andre Poenitz]

On Wed, Nov 13, 2002 at 05:37:48PM +1000, Allan Rae wrote:
> Or as a minimal tweak move the params.temp_bullets to the
> dialog/controller.

This sounds ok to me.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 2. the bullets

 I need to set the bullet codes. for now I have put them in the new files
 bulletstrings.[Ch]. I don't know what is best. move them out of bullet.[Ch]
 to tex-strings[Ch]?

could someone comment on this before I commit (it's not qt related)

Thanks, Ed.

Re: bullets in qt

[Andre Poenitz]

On Mon, Nov 11, 2002 at 01:05:00PM +, Edwin Leuven wrote:
  2. the bullets
 
  I need to set the bullet codes. for now I have put them in the new files
  bulletstrings.[Ch]. I don't know what is best. move them out of bullet.[Ch]
  to tex-strings[Ch]?
 
 could someone comment on this before I commit (it's not qt related)

Well, I don't know the old code nor do I know what exactly you need nor do
I think that bullet access in the GUI is very important.

Does this count as comment? ;-)

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 Does this count as comment? ;-)

I guess not ;-)

At the moment the various bullets are put/defined in static strings within the 
Bullet class. If you have a look in Bullet.C you will see this in 
bulletEntry(int,int). 

Thing is that I need them so that users can set custom bullets using the UI.

Ed.

Re: bullets in qt

[Andre Poenitz]

On Mon, Nov 11, 2002 at 01:33:04PM +, Edwin Leuven wrote:
  Does this count as comment? ;-)
 
 I guess not ;-)
 
 At the moment the various bullets are put/defined in static strings
 within the Bullet class. If you have a look in Bullet.C you will see this
 in bulletEntry(int,int). 

I wonder why such a bullet can't be a thin wrapper around a std::string
like \ding{49}?  Is this just a performance enhancement?

 Thing is that I need them so that users can set custom bullets using the
 UI.

You need the strings?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 I wonder why such a bullet can't be a thin wrapper around a std::string
 like \ding{49}?  Is this just a performance enhancement?

don't ask me

 You need the strings?

yep

Re: bullets in qt

[Andre Poenitz]

On Mon, Nov 11, 2002 at 01:51:43PM +, Edwin Leuven wrote:
  You need the strings?
 
 yep

Your bulletstring.[hC] approach looks ok to me.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: bullets in qt

[Edwin Leuven]

 Your bulletstring.[hC] approach looks ok to me.

I'll commit then.

Thanks, Ed.

Re: bullets in qt

[Juergen Spitzmueller]

Edwin Leuven wrote:
 For some reason QBrowseBox doesn't get mouse focus.

Fix attached.

(Have a look at
http://doc.trolltech.com/3.0/qscrollview.html#details
for details)

Regards,
Jürgen.
Index: src/frontends/qt2/QBrowseBox.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/QBrowseBox.C,v
retrieving revision 1.7
diff -u -r1.7 QBrowseBox.C
--- src/frontends/qt2/QBrowseBox.C	2002/11/08 00:09:00	1.7
+++ src/frontends/qt2/QBrowseBox.C	2002/11/11 15:30:51
 -44,9 +44,9 
 	else
 		setFrameStyle(QFrame::Panel | QFrame::Raised);
 
-	setFocusPolicy(QWidget::StrongFocus);
+	viewport()-setFocusPolicy(QWidget::StrongFocus);
 	// setMouseTracking must be called after setFocusPolicy
-	setMouseTracking(true);
+	viewport()-setMouseTracking(true);
 	inloop=false;
 	
 }
 -209,7 +209,7 
 	}
 }
 
-void QBrowseBox::mouseReleaseEvent(QMouseEvent *)
+void QBrowseBox::contentsMouseReleaseEvent(QMouseEvent *)
 {
 
 	if (firstrelease_)
 -267,12 +267,12 
 }
 
 
-void QBrowseBox::mouseMoveEvent(QMouseEvent * e)
+void QBrowseBox::contentsMouseMoveEvent(QMouseEvent * e)
 {
 	qWarning(mouseMoveEvent);
 	int x = e-pos().x();
 	int y = e-pos().y();
-
+	
 	int cellx;
 	int celly;
 
Index: src/frontends/qt2/QBrowseBox.h
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/QBrowseBox.h,v
retrieving revision 1.5
diff -u -r1.5 QBrowseBox.h
--- src/frontends/qt2/QBrowseBox.h	2002/11/08 00:09:00	1.5
+++ src/frontends/qt2/QBrowseBox.h	2002/11/11 15:30:52
 -48,16 +48,16 
 	
 protected:
 	virtual void keyPressEvent(QKeyEvent * e);
-	virtual void resizeEvent(QResizeEvent * e);
-	virtual void mouseReleaseEvent(QMouseEvent * e);
+	virtual void resizeEvent(QResizeEvent *e);
+	virtual void contentsMouseReleaseEvent(QMouseEvent *);
 	virtual void closeEvent(QCloseEvent * e);
-	virtual void mouseMoveEvent(QMouseEvent * e);
+	virtual void contentsMouseMoveEvent(QMouseEvent * e);
 	virtual void paintCell(QPainter *, int row, int col);
 	
 private:
 	// make sure the automatically generated one is not used
 	QBrowseBox  operator=(QBrowseBox const );
-	
+
 	void moveLeft();
 	void moveRight();
 	void moveUp();

Re: bullets in qt

[Edwin Leuven]

 Fix attached.

Thanks!

Applying bullets is still rotten though, so I won't apply for the moment.

Cheers, Ed.

Re: bullets in qt

[Allan Rae]

On Mon, 11 Nov 2002, Andre Poenitz wrote:

 On Mon, Nov 11, 2002 at 01:33:04PM +, Edwin Leuven wrote:
   Does this count as comment? ;-)
 
  I guess not ;-)
 
  At the moment the various bullets are put/defined in static strings
  within the Bullet class. If you have a look in Bullet.C you will see this
  in bulletEntry(int,int).

 I wonder why such a bullet can't be a thin wrapper around a std::string
 like \ding{49}?  Is this just a performance enhancement?

It was more a matter of:  it's easier to generate the string from a
table of the known bullets that it is/was to attempt to remap a string
to a bullet table position.

The thing is the bullet tabs were always supposed to have the current
bullet pushed for whatever level you were setting (ie. the
pseudo-push-button was supposed to be indented but that never worked
because of limitations in the image map thingy.

A string is stored however for those cases where a person decides to
customise the latex command -- such as wanting a rotated \ding{49}.

  Thing is that I need them so that users can set custom bullets using the
  UI.

 You need the strings?

All of them at once?  Why?
Why couldn't you just request the string when the appropriate button
is pushed?  That is, use a Bullet as a lookup table.  I haven't looked
at your code yet.  But I don't see why you need to change this -- even
loading the pixmaps into the respective buttons on a bullets tab
shouldn't have needed removing the strings.  Maybe I'm forgetting
something after all I wrote this stuff about 6 years ago.

Allan. (ARRae)

Re: bullets in qt

[Edwin Leuven]

> 2. the bullets
>
> I need to set the bullet codes. for now I have put them in the new files
> bulletstrings.[Ch]. I don't know what is best. move them out of bullet.[Ch]
> to tex-strings[Ch]?

could someone comment on this before I commit (it's not qt related)

Thanks, Ed.

Re: bullets in qt

[Andre Poenitz]

On Mon, Nov 11, 2002 at 01:05:00PM +, Edwin Leuven wrote:
> > 2. the bullets
> >
> > I need to set the bullet codes. for now I have put them in the new files
> > bulletstrings.[Ch]. I don't know what is best. move them out of bullet.[Ch]
> > to tex-strings[Ch]?
> 
> could someone comment on this before I commit (it's not qt related)

Well, I don't know the old code nor do I know what exactly you need nor do
I think that bullet access in the GUI is very important.

Does this count as comment? ;-)

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)