Helge Hafting <[EMAIL PROTECTED]> writes:
> Ah, I didn't think of that. And the extra options never clash
> in ways where the right option for one package wrecks another?
I do not know of any such case, but it could happen indeed.
JMarc
Jean-Marc Lasgouttes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
(...)
The problem is, you either support things through the
preamble or some dialog, but not both.
If you use the listing support, where in the preamble would
you put an additional option? That don't work in practice. Ther
Leuven, E. wrote:
i would prefer a simple lineedit as with the document class options and would
expect people who use this functionality to read the listings documentation.
so i do not see the urgency of validating the input and duplicating the
documentation in a separate hints window. we don'
Leuven, E. wrote:
Helge Hafting wrote:
The problem is, you either support things through the
preamble or some dialog, but not both.
let me guess, the law of hafting?
No. Feel free to implement stuff that way, I described how
LyX works now.
If you use the listing support, where in
Edwin Leuven wrote:
However, this is very Qt/Gui intensive and I certainly do not have the
needed knowledge to do it. As a matter of fact, I asked help for
similar things when I design the listing dialog but everyone was busy.
people were busy and you were in a rush i seem to remember ;-)
i wou
Bo Peng wrote:
still think that an autogenerated properties dialog will be even better
though...
This is exactly what I proposed.
oops
The whole idea is not that difficult, we simply need a few text files
with fields like
parameter name, group name, type, hint, default value, validation
ty
> still think that an autogenerated properties dialog will be even better
> though...
This is exactly what I proposed.
> the information you have put now in ParValidator::ParValidator() could
> be parsed to build the dialog
Yes.
> if there are a lot of parameters as with listing i am sure they
Bo Peng wrote:
We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyperref/whatever options' is triggered.
3. This dialog has all the val
José Matos wrote:
On Thursday 13 September 2007 17:40:10 Bo Peng wrote:
We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyper
Pavel Sanda wrote:
So you guys are willing to remove validation and allow the input of
arbitrary (wrong) parameters, just to make the dialog look prettier?
if you remove the validation from listings now, there will be screem
from users already using it. if it hasnt been shot down before 1.5.0
r
On Thursday 13 September 2007 17:40:10 Bo Peng wrote:
> > We call it consistent behaviour. ;-)
>
> Then we can implement a 'compose' dialog, that
>
> 1. Option [params ] Compose_Button
>
> 2. When the compose button is pressed, dialog 'compose
> listings/hyperref/whatever opt
> So you guys are willing to remove validation and allow the input of
> arbitrary (wrong) parameters, just to make the dialog look prettier?
if you remove the validation from listings now, there will be screem
from users already using it. if it hasnt been shot down before 1.5.0
release, its afaik
On Thursday 13 September 2007 17:23:23 Bo Peng wrote:
> You know how much time I spent on this validation system, and on the
> AUTO embedding feature?
Much indeed. :-)
The validation is nice and I would like to see it extended to other places.
But I would like to see that happen in a smooth a
> We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyperref/whatever options' is triggered.
3. This dialog has all the validation faciliti
> We call it consistent behaviour. ;-)
>
> Note that the problem happens as well for other packages. Again it would be
> nice to have a general solution. The point is not to look prettier but to
> have the same look and feel everywhere, the principle of least surprise. (not
> sure if this is th
On Thursday 13 September 2007 16:32:11 Bo Peng wrote:
> So you guys are willing to remove validation and allow the input of
> arbitrary (wrong) parameters, just to make the dialog look prettier?
We call it consistent behaviour. ;-)
Note that the problem happens as well for other packages. Aga
> > i would prefer a simple lineedit as with the document class options
> > and would expect people who use this functionality to read the
> > listings documentation.
> >
> > so i do not see the urgency of validating the input and duplicating
> > the documentation in a separate hints window. we don
"Leuven, E." <[EMAIL PROTECTED]> writes:
> i would prefer a simple lineedit as with the document class options
> and would expect people who use this functionality to read the
> listings documentation.
>
> so i do not see the urgency of validating the input and duplicating
> the documentation in a
i would prefer a simple lineedit as with the document class options and would
expect people who use this functionality to read the listings documentation.
so i do not see the urgency of validating the input and duplicating the
documentation in a separate hints window. we don't do that with the d
> now there is a big textedit with an ugly "documentation" field next to it and
> that i don't like so much:
If you can think of a better-looking alternative to display hints and
error messages, I will be quite happy to change that. (I do not like
that very much either)
Bo
Helge Hafting <[EMAIL PROTECTED]> writes:
> Edwin Leuven wrote:
>> Bo Peng wrote:
>>> But there is no way to GUI'ify all 163 listings parameters.
>>
>> support the important ones and if people want to set the others they
>> can use the preamble?
> The problem is, you either support things through
Helge Hafting wrote:
> The problem is, you either support things through the
> preamble or some dialog, but not both.
let me guess, the law of hafting?
> If you use the listing support, where in the preamble would
> you put an additional option?
in the case of the listings package i had the impr
Edwin Leuven wrote:
Bo Peng wrote:
But there is no way to GUI'ify all 163 listings parameters.
support the important ones and if people want to set the others they
can use the preamble?
The problem is, you either support things through the
preamble or some dialog, but not both.
If you use th
"Leuven, E." <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> But it is difficult to have a good loking UI in this case, where
>> auto-generating does not show.
>
> i guess it could look like the property editor in qt's designer
Where is that? I am not very fluent with this program...
Jean-Marc Lasgouttes wrote:
> But it is difficult to have a good loking UI in this case, where
> auto-generating does not show.
i guess it could look like the property editor in qt's designer
that would be fine with me though (and things would also have a consistent look
'n feel)...
Edwin Leuven <[EMAIL PROTECTED]> writes:
>
> it would be nice to have package definitions in modules from which we
> could auto-generate a properties dialogs, both for the package and the
> environments it defines...
>
But it is difficult to have a good loking UI in this case, where
auto-genera
Bo Peng wrote:
But there is no way to GUI'ify all 163 listings parameters.
support the important ones and if people want to set the others they can
use the preamble?
it would be nice to have package definitions in modules from which we
could auto-generate a properties dialogs, both for the
On Wednesday 12 September 2007 22:18:43 Bo Peng wrote:
> But there is no way to GUI'ify all 163 listings parameters.
We do not do it for other packages. We should try to be consistent
everywhere.
> > In a sense it is to bare to lyx. IMHO we need to improve that.
> > The label is not on line wi
On 9/12/07, José Matos <[EMAIL PROTECTED]> wrote:
> On Wednesday 12 September 2007 15:12:55 Bo Peng wrote:
> > > Another way is to just have the most interesting options, and
> > > a text entry field for the rest. Much cleaner, but with the
> > > disadvantage that that users can enter latex-crashin
On Wednesday 12 September 2007 15:12:55 Bo Peng wrote:
> > Another way is to just have the most interesting options, and
> > a text entry field for the rest. Much cleaner, but with the
> > disadvantage that that users can enter latex-crashing
> > syntax errors in the entry field.
>
> This is what l
> 1) afaiu strings entered into gui are in utf8; now they are pasted to output
> .tex via from_utf8,
>but i'm not sure how it works with current encodings. whats the best
> solution for this ?
have anybody some idea how to get working characters from other encodings when
passed
in preamble
Pavel Sanda wrote:
It might be that, if we load hyperref at the right point---and
obviously, we have to figure out when that is---these sorts of issues
will go away.
Be careful. The only thing that delayed hyperref support is all the
incompatibilities we are going to encounter (like insi
> Yes, this package has many options, and it seems many of them are
> actually used too. I find it nice not having to use ERT to use
> a package when LyX supports it. Especially for people with no
> latex background.
True.
> If we want to support many hyperref options, then a tabbed
> dialog migh
Uwe Stöhr wrote:
[long examples of hyperref options deleted]
So you can see that it is impossible to support all options by
checkboxes. Especially when you have an option for evey color setting,
the dialog becomes overfull.
Yes, this package has many options, and it seems many of them are
act
> This is how I use hyperref currently:
> \usepackage[breaklinks=true,colorlinks=true,bookmarks=true,
> bookmarksopen=true,bookmarksnumbered=true]{hyperref}
>
> So obviously I'll find it nice if these options are supported,
> possibly in the form of checkboxes. Ability to set the link colors
> wou
> > It might be that, if we load hyperref at the right point---and
> > obviously, we have to figure out when that is---these sorts of issues
> > will go away.
>
> Be careful. The only thing that delayed hyperref support is all the
> incompatibilities we are going to encounter (like insisting that
Pavel Sanda wrote:
hi,
i have basic working skeleton for bug 3527; now there is only minimal set of
supported features, but i'll add others, when you won't opose the general
construction of this code. i would like to ask :
1) is it possible to add hyperref support to 1.6 series (Jose?)
2) can s
Jean-Marc Lasgouttes schrieb:
Be careful. The only thing that delayed hyperref support is all the
incompatibilities we are going to encounter (like insisting that
\label{} should be outside of a \section{}).
This doesn't make problems as far as I know. Currently \labels are still set by LyX in
> http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif
> that is the current state on my local branch. still receiving additional
> requests :)
Two things:
- bookmarksopen opens all bookmark levels, what is missing is a box to adjust the level number. This
box should only be activated when bookm
Richard Heck <[EMAIL PROTECTED]> writes:
> It might be that, if we load hyperref at the right point---and
> obviously, we have to figure out when that is---these sorts of issues
> will go away.
Be careful. The only thing that delayed hyperref support is all the
incompatibilities we are going to
On 9/11/07, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > 1. "PDF support" may not be the best name. I am thinking of "Document
> > Properties", but "Hyperref Support" may be clearer.
>
> users with a little knowledge of latex will not understand Hyperref Support.
> Document Properties is too general.
> 1. "PDF support" may not be the best name. I am thinking of "Document
> Properties", but "Hyperref Support" may be clearer.
users with a little knowledge of latex will not understand Hyperref Support.
Document Properties is too general. we can change the naming, but still
i think that the keywor
> http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif
> that is the current state on my local branch. still receiving additional
> requests :)
Nice dialog. I think
1. "PDF support" may not be the best name. I am thinking of "Document
Properties", but "Hyperref Support" may be clearer.
2. This pa
> Probably there should just be a "use hyperref" checkbox to turn this on
> and off. You could then check that and get basic hyperref support
> without actually having to fill out any of the fields. That is: You'd
> just get \usepackage{hyperref}. As for other checkboxes, we should have
> ones
Uwe Stöhr wrote:
> And if you're working on thisthe URL inset should become an
\href inset. (There are a billion > bugs about this.)
I also opted for this often in the past, but you need to take care
then of several issues. Take for example the Algorithm floats:
The EmbeddedObjects manual
> And if you're working on thisthe URL inset should become an \href inset. (There are a billion
> bugs about this.)
I also opted for this often in the past, but you need to take care then of several issues. Take for
example the Algorithm floats:
The EmbeddedObjects manual describes a lot o
Pavel Sanda wrote:
Probably there should just be a "use hyperref" checkbox to turn this on and
off. You could then check that and get basic hyperref support without
actually having to fill out any of the fields. That is: You'd just get
\usepackage{hyperref}.
have never used this plain vers
> Probably there should just be a "use hyperref" checkbox to turn this on and
> off. You could then check that and get basic hyperref support without
> actually having to fill out any of the fields. That is: You'd just get
> \usepackage{hyperref}.
have never used this plain version. does it anyth
> > 2) can somebody review this code and comment what should be done
> >otherwise and mainly what i forgot to do.
>
> I have a quick look at the patch, and have one question though: why do
> you use separate file for PDFOptions.h|cpp? I guess it can be merged
basically because i mimic some ot
Bo Peng wrote:
2) can somebody review this code and comment what should be done
otherwise and mainly what i forgot to do.
I have a quick look at the patch, and have one question though: why do
you use separate file for PDFOptions.h|cpp? I guess it can be merged
to BufferParams.
Yes, I
> i have basic working skeleton for bug 3527; now there is only minimal set of
> supported features, but i'll add others, when you won't opose the general
> construction of this code. i would like to ask :
Nice work!
> 1) is it possible to add hyperref support to 1.6 series (Jose?)
As long as yo
hi,
i have basic working skeleton for bug 3527; now there is only minimal set of
supported features, but i'll add others, when you won't opose the general
construction of this code. i would like to ask :
1) is it possible to add hyperref support to 1.6 series (Jose?)
2) can somebody review this c
52 matches
Mail list logo
