Pavel Sanda wrote:
Juergen, i would like to have this in branch too. pavel
OK, but I have some minor question and comments on the changes:
Modified: lyx-devel/trunk/lib/ui/stdmenus.inc
== ---
Rob Oakes wrote:
btw Rob, in this second mail you sent the attachment in (desirable) plain form,
so one can comment on it directly, please remember how you did it :)
thanks
pavel
rgheck rgh...@bobjweil.com writes:
Yes, I have been following it, distantly, and am in effect endorsing
the old solution, plus some additional granularity. Your worries about
the new attempt seem to me reasonable ones.
I'll let Uwe decide on what he wants to do.
Nevertheless, concerning what
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
Juergen, i would like to have this in branch too. pavel
OK, but I have some minor question and comments on the changes:
Modified: lyx-devel/trunk/lib/ui/stdmenus.inc
Pavel Sanda wrote:
+ OptItem Toggle locking property|T vc-locking-toggle
Please unify the casing, i.e. Toggle Locking Property|T
will fix it
Also, I'm not sure I understood this feature, but wouldn't a string such
as Lock File in Repository be more adequate?
No,
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
+ OptItem Toggle locking property|T vc-locking-toggle
Please unify the casing, i.e. Toggle Locking Property|T
will fix it
Also, I'm not sure I understood this feature, but wouldn't a string such
as Lock File in
Pavel Sanda wrote:
But if it's a toggle, how is the user supposed to see whether s/he toggles
the
locking mechanism on or off?
its very similar to register function. if you used it you have to remember
until
you commit it. once you commit it, it can be recognized by the state of the
Pavel Sanda sa...@lyx.org writes:
Also, I'm not sure I understood this feature, but wouldn't a string such as
Lock File in Repository be more adequate?
No, because it doesn't lock anything. Locking is done by svn when
updating/commiting and this command just tells svn that it should use
Pavel Sanda wrote:
i was wrong that we do not use automatical check of properties once we are
under svn control -- we use it...
which leads me to the idea how to add revision info into bufferparams in the
current state of things :)
pavel
Pavel Sanda wrote:
you can recognize locking state enabled by title and vc toolbar
once you commited it.
So why don't you use that information to set flag.setOnOff and rename the menu
entry to Use Locking Property?
Menu items should be self-explanatory, without the need to memorize actions or
Jean-Marc Lasgouttes wrote:
#: lib/ui/stdcontext.inc:133
msgid Toggle Label|L
--
Of these, only the last one is interesting, since we do not change
classic.ui anymore (although we may want to make them in line with
default?)
This last one should changed to Show Label,
Indeed.
but I do
Jürgen Spitzmüller wrote:
Of these, only the last one is interesting, since we do not change
classic.ui anymore (although we may want to make them in line with
default?)
This last one should changed to Show Label,
Indeed.
Since the checkbox was already there, I just changed the
Jürgen Spitzmüller wrote:
Since the checkbox was already there, I just changed the string.
As far as branch is concerned, we have some more occurrences. See attached
patch. Before I commit: is this part OK or did the semantics of math-number-
toggle change in trunk?
- OptItem
Jürgen Spitzmüller wrote:
As far as branch is concerned, we have some more occurrences. See attached
patch. Before I commit: is this part OK or did the semantics of
math-number- toggle change in trunk?
- OptItem Toggle Labeling/Numbering|T math-number-toggle
+
Jean-Marc Lasgouttes wrote:
So you mean Use Locking Property ?
yes.
I do not like the verb toggle in
the UI context.
Feel free to suggest better naming. We use it anyway in different UIs
$ cat cs.po|grep -i toggle|grep -v ^#|wc -l
16
This kind of grepping is irrelevant. The
Pavel Sanda wrote:
This kind of grepping is irrelevant. The question here is about menus.
i didnt get you talk only about menus. is there any way how to make
toolbar icon tristate?
What do you mean by tristate? Toolbar buttons also have the onOff and
enabled/disabled facility.
Jürgen
sanda wrote:
if (enable)
flag.setOnOff(!buf-lyxvc().locker().empty());
or rather
flag.setOnOff(enabled !buf-lyxvc().locker().empty());
?
Jürgen
Jürgen Spitzmüller wrote:
sanda wrote:
if (enable)
flag.setOnOff(!buf-lyxvc().locker().empty());
or rather
flag.setOnOff(enabled !buf-lyxvc().locker().empty());
?
i thought in disabled state you wont recognize toolbar on/off. i will fix it.
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
This kind of grepping is irrelevant. The question here is about menus.
i didnt get you talk only about menus. is there any way how to make
toolbar icon tristate?
What do you mean by tristate? Toolbar buttons also have the onOff and
Jürgen Spitzmüller wrote:
+string LyXVC::lockingToggle()
+{
+ LYXERR(Debug::LYXVC, LyXVC: toggle locking property);
+ return vcs-lockingToggle();
Here, you don't need to check if vcs is valid, i.e.
return vcs vcs-lockingToggle();
as in lockingToggleEnabled() below?
Pavel Sanda wrote:
i meant enabled_on/enabled_off/disable. and i saw meanwhile it works...
hope you are more happy now ;)
Yes. Thanks.
Jürgen
currently i see
GuiImage.cpp: In member function 'bool lyx::graphics::GuiImage::scale(const
lyx::graphics::Params)':
GuiImage.cpp:168: warning: comparison of unsigned expression 0 is always false
which is because
unsigned int scale;
if (params.scale 0 || params.scale == 100)
Christian Ridderström wrote:
Feel free to correct the title, e.g. by adding this:
(:title AMS (for LyX 1.4.x and 1.5.x) :)
or whatever title text you want.
Tried that, but it broke the entry on the page list for the Layouts
section (the link to the Layouts/AMS page was there, but the
Christian Ridderström wrote:
Btw, I think you should add a list of contributors, and some way to get
in contact (which could of course be through the users' or developers'
list).
Ok, I put a hint about this at the top of LyX/Modules and took the blame
for the two sets of files I
Pavel Sanda wrote:
Abdelrazak Younes wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters for more counters in named document
and master/child usage).
Jean-Marc Lasgouttes wrote:
rgheck rgh...@bobjweil.com writes:
Yes, I have been following it, distantly, and am in effect endorsing
the old solution, plus some additional granularity. Your worries about
the new attempt seem to me reasonable ones.
I'll let Uwe decide on what he wants
Richard Heck wrote:
Pavel Sanda wrote:
Abdelrazak Younes wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters for more counters in named document
and
Pavel Sanda wrote:
Richard Heck wrote:
Pavel Sanda wrote:
Abdelrazak Younes wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters
Richard Heck wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters for more counters in named
document
and master/child usage).
I think
i want some inset, which i can put anywhere in the text which output
single
number which is incremented + 1 to previous inset. and i do not want
to edit
some preamble stuff to do this, just something from the insert menu,
as any
normal user would expect.
So you want an object that does
Also, I'm not sure I understood this feature, but wouldn't a string such as
Lock File in Repository be more adequate? I do not like the verb toggle in
the UI context. Also, I would use a menu checkbox (FuncFlags::setOnOff) that
is checked if the file is locked. Then you'd have three states:
Jürgen Spitzmüller schreef:
Jürgen Spitzmüller wrote:
Since the checkbox was already there, I just changed the string.
As far as branch is concerned, we have some more occurrences. See attached
patch. Before I commit: is this part OK or did the semantics of math-number-
toggle
Pavel Sanda schreef:
currently i see
GuiImage.cpp: In member function 'bool lyx::graphics::GuiImage::scale(const
lyx::graphics::Params)':
GuiImage.cpp:168: warning: comparison of unsigned expression 0 is always false
which is because
unsigned int scale;
if (params.scale 0 ||
On Fri, 26 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
Btw, I think you should add a list of contributors, and some way to get in
contact (which could of course be through the users' or developers' list).
Ok, I put a hint about this at the top of LyX/Modules and took the
On Fri, 26 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
Feel free to correct the title, e.g. by adding this:
(:title AMS (for LyX 1.4.x and 1.5.x) :)
or whatever title text you want.
Tried that, but it broke the entry on the page list for the Layouts section
(the link
Pavel Sanda wrote:
Richard Heck wrote:
how i do it in lyx? o we have some module?
It depends exactly what you need, but you can define counters like this:
i want some inset, which i can put anywhere in the text which output single
number which is incremented + 1 to
Paul A. Rubin wrote:
Ok, I put a hint about this at the top of LyX/Modules and took the blame
for the two sets of files I uploaded. Incidentally, I noticed that the
Modules upload directory already existed and contained a file
(nomindex.module), but I have no idea who the donor is (not listed
Vincent van Ravesteijn wrote:
Shouldn't it be Number Whole Formula|N and Number This Line, as I
read that the casing should be unified ?
Yes. The stdcontext file is not very coherent in style.
I'll fix that.
Jürgen
Jürgen Spitzmüller wrote:
Vincent van Ravesteijn wrote:
Shouldn't it be Number Whole Formula|N and Number This Line, as I
read that the casing should be unified ?
Yes. The stdcontext file is not very coherent in style.
And not only that.
After re-consulting a HIG (the Gnome HIG since
Pavel Sanda wrote:
> Juergen, i would like to have this in branch too. pavel
OK, but I have some minor question and comments on the changes:
>Modified: lyx-devel/trunk/lib/ui/stdmenus.inc
>
>== ---
Rob Oakes wrote:
btw Rob, in this second mail you sent the attachment in (desirable) plain form,
so one can comment on it directly, please remember how you did it :)
thanks
pavel
rgheck writes:
> Yes, I have been following it, distantly, and am in effect endorsing
> the old solution, plus some additional granularity. Your worries about
> the new attempt seem to me reasonable ones.
I'll let Uwe decide on what he wants to do.
Nevertheless, concerning
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > Juergen, i would like to have this in branch too. pavel
>
> OK, but I have some minor question and comments on the changes:
>
> >Modified: lyx-devel/trunk/lib/ui/stdmenus.inc
>
Pavel Sanda wrote:
> > >+ OptItem "Toggle locking property|T" "vc-locking-toggle"
> >
> > Please unify the casing, i.e. "Toggle Locking Property|T"
>
> will fix it
>
> > Also, I'm not sure I understood this feature, but wouldn't a string such
> > as "Lock File in Repository" be more
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > > >+ OptItem "Toggle locking property|T" "vc-locking-toggle"
> > >
> > > Please unify the casing, i.e. "Toggle Locking Property|T"
> >
> > will fix it
> >
> > > Also, I'm not sure I understood this feature, but wouldn't a string such
Pavel Sanda wrote:
> > But if it's a toggle, how is the user supposed to see whether s/he toggles
> > the
> > locking mechanism on or off?
>
> its very similar to register function. if you used it you have to remember
> until
> you commit it. once you commit it, it can be recognized by the
Pavel Sanda writes:
>> Also, I'm not sure I understood this feature, but wouldn't a string such as
>> "Lock File in Repository" be more adequate?
>
> No, because it doesn't lock anything. Locking is done by svn when
> updating/commiting and this command just tells svn that it
Pavel Sanda wrote:
> i was wrong that we do not use automatical check of properties once we are
> under svn control -- we use it...
which leads me to the idea how to add revision info into bufferparams in the
current state of things :)
pavel
Pavel Sanda wrote:
> you can recognize locking state enabled by title and vc toolbar
> once you commited it.
So why don't you use that information to set flag.setOnOff and rename the menu
entry to "Use Locking Property"?
Menu items should be self-explanatory, without the need to memorize
Jean-Marc Lasgouttes wrote:
> #: lib/ui/stdcontext.inc:133
> msgid "Toggle Label|L"
> --
>
> Of these, only the last one is interesting, since we do not change
> classic.ui anymore (although we may want to make them in line with
> default?)
>
> This last one should changed to "Show Label",
Jürgen Spitzmüller wrote:
> > Of these, only the last one is interesting, since we do not change
> > classic.ui anymore (although we may want to make them in line with
> > default?)
> >
> > This last one should changed to "Show Label",
>
> Indeed.
Since the checkbox was already there, I just
Jürgen Spitzmüller wrote:
> Since the checkbox was already there, I just changed the string.
As far as branch is concerned, we have some more occurrences. See attached
patch. Before I commit: is this part OK or did the semantics of math-number-
toggle change in trunk?
- OptItem
Jürgen Spitzmüller wrote:
> As far as branch is concerned, we have some more occurrences. See attached
> patch. Before I commit: is this part OK or did the semantics of
> math-number- toggle change in trunk?
>
> - OptItem "Toggle Labeling/Numbering|T" "math-number-toggle"
> +
Jean-Marc Lasgouttes wrote:
> So you mean "Use Locking Property" ?
yes.
> >>I do not like the verb "toggle" in
> >> the UI context.
> >
> > Feel free to suggest better naming. We use it anyway in different UIs
> > $ cat cs.po|grep -i toggle|grep -v ^#|wc -l
> > 16
>
> This kind of grepping
Pavel Sanda wrote:
> > This kind of grepping is irrelevant. The question here is about menus.
>
> i didnt get you talk only about menus. is there any way how to make
> toolbar icon tristate?
What do you mean by "tristate"? Toolbar buttons also have the onOff and
enabled/disabled facility.
sanda wrote:
> if (enable)
> flag.setOnOff(!buf->lyxvc().locker().empty());
or rather
flag.setOnOff(enabled && !buf->lyxvc().locker().empty());
?
Jürgen
Jürgen Spitzmüller wrote:
> sanda wrote:
> > if (enable)
> > flag.setOnOff(!buf->lyxvc().locker().empty());
>
> or rather
> flag.setOnOff(enabled && !buf->lyxvc().locker().empty());
> ?
i thought in disabled state you wont recognize toolbar on/off. i
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > > This kind of grepping is irrelevant. The question here is about menus.
> >
> > i didnt get you talk only about menus. is there any way how to make
> > toolbar icon tristate?
>
> What do you mean by "tristate"? Toolbar buttons also have the
Jürgen Spitzmüller wrote:
> >+string LyXVC::lockingToggle()
> >+{
> >+ LYXERR(Debug::LYXVC, "LyXVC: toggle locking property");
> >+ return vcs->lockingToggle();
>
> Here, you don't need to check if vcs is valid, i.e.
>
> return vcs && vcs->lockingToggle();
>
> as in
Pavel Sanda wrote:
> i meant enabled_on/enabled_off/disable. and i saw meanwhile it works...
> hope you are more happy now ;)
Yes. Thanks.
Jürgen
currently i see
GuiImage.cpp: In member function 'bool lyx::graphics::GuiImage::scale(const
lyx::graphics::Params&)':
GuiImage.cpp:168: warning: comparison of unsigned expression < 0 is always false
which is because
unsigned int scale;
if (params.scale < 0 || params.scale == 100)
Christian Ridderström wrote:
Feel free to correct the title, e.g. by adding this:
(:title AMS (for LyX 1.4.x and 1.5.x) :)
or whatever title text you want.
Tried that, but it "broke" the entry on the page list for the Layouts
section (the link to the Layouts/AMS page was there, but the
Christian Ridderström wrote:
Btw, I think you should add a list of contributors, and some way to get
in contact (which could of course be through the users' or developers'
list).
Ok, I put a hint about this at the top of LyX/Modules and took the blame
for the two sets of files I
Pavel Sanda wrote:
Abdelrazak Younes wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters for more counters in named document
and master/child usage).
Jean-Marc Lasgouttes wrote:
rgheck writes:
Yes, I have been following it, distantly, and am in effect endorsing
the old solution, plus some additional granularity. Your worries about
the new attempt seem to me reasonable ones.
I'll let Uwe decide on what he wants
Richard Heck wrote:
> Pavel Sanda wrote:
>> Abdelrazak Younes wrote:
>>
>>> Is this InsetCounter a good idea? Could this be based on InsetFlex?
>>>
>>
>> i would use such kind of inset myself and have already been thinking
>> how to add it ;) (maybe named counters for more counters in
Pavel Sanda wrote:
Richard Heck wrote:
Pavel Sanda wrote:
Abdelrazak Younes wrote:
Is this InsetCounter a good idea? Could this be based on InsetFlex?
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters
Richard Heck wrote:
> Is this InsetCounter a good idea? Could this be based on InsetFlex?
>
i would use such kind of inset myself and have already been thinking
how to add it ;) (maybe named counters for more counters in named
document
and master/child
i want some inset, which i can put anywhere in the text which output
single
number which is incremented + 1 to previous inset. and i do not want
to edit
some preamble stuff to do this, just something from the insert menu,
as any
normal user would expect.
So you want an object that does
Also, I'm not sure I understood this feature, but wouldn't a string such as
"Lock File in Repository" be more adequate? I do not like the verb "toggle" in
the UI context. Also, I would use a menu checkbox (FuncFlags::setOnOff) that
is checked if the file is locked. Then you'd have three
Jürgen Spitzmüller schreef:
Jürgen Spitzmüller wrote:
Since the checkbox was already there, I just changed the string.
As far as branch is concerned, we have some more occurrences. See attached
patch. Before I commit: is this part OK or did the semantics of math-number-
toggle
Pavel Sanda schreef:
currently i see
GuiImage.cpp: In member function 'bool lyx::graphics::GuiImage::scale(const
lyx::graphics::Params&)':
GuiImage.cpp:168: warning: comparison of unsigned expression < 0 is always false
which is because
unsigned int scale;
if (params.scale < 0 ||
On Fri, 26 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
Btw, I think you should add a list of contributors, and some way to get in
contact (which could of course be through the users' or developers' list).
Ok, I put a hint about this at the top of LyX/Modules and took the
On Fri, 26 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
Feel free to correct the title, e.g. by adding this:
(:title AMS (for LyX 1.4.x and 1.5.x) :)
or whatever title text you want.
Tried that, but it "broke" the entry on the page list for the Layouts section
(the
Pavel Sanda wrote:
Richard Heck wrote:
how i do it in lyx? o we have some module?
It depends exactly what you need, but you can define counters like this:
i want some inset, which i can put anywhere in the text which output single
number which is incremented + 1 to
Paul A. Rubin wrote:
> Ok, I put a hint about this at the top of LyX/Modules and took the blame
> for the two sets of files I uploaded. Incidentally, I noticed that the
> Modules upload directory already existed and contained a file
> (nomindex.module), but I have no idea who the donor is (not
Vincent van Ravesteijn wrote:
> Shouldn't it be "Number Whole Formula|N" and "Number This Line", as I
> read that the casing should be unified ?
Yes. The stdcontext file is not very coherent in style.
I'll fix that.
Jürgen
Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > Shouldn't it be "Number Whole Formula|N" and "Number This Line", as I
> > read that the casing should be unified ?
>
> Yes. The stdcontext file is not very coherent in style.
And not only that.
After re-consulting a HIG (the Gnome HIG
78 matches
Mail list logo