Bo Peng wrote:
>> Like this? This time also the ui file.
>>
>
> I get
>
> In file included from src/frontends/qt4/QListings.h:16,
> from src/frontends/qt4/Dialogs.cpp:70:
> debug/common/frontends/qt4/ui/ListingsUi.h: In member function `void
> Ui_QListingsUi::setupUi(QDialog*)':
>
On 5/10/07, Peter Kümmel <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> Like this? This time also the ui file.
I get the same error. I guess I miss a header file somewhere and your
cmake's pch stuff can not detect it.
Bo
Bo Peng wrote:
>> Like this? This time also the ui file.
>>
>
With attached ui file I get attached dialog.
Does it still not work?
Peter
QListingsUi
Qt::ApplicationModal
0
0
448
417
Listing
true
6
Like this? This time also the ui file.
I get
In file included from src/frontends/qt4/QListings.h:16,
from src/frontends/qt4/Dialogs.cpp:70:
debug/common/frontends/qt4/ui/ListingsUi.h: In member function `void
Ui_QListingsUi::setupUi(QDialog*)':
debug/common/frontends/qt4/ui/Lis
Bo Peng wrote:
>> There is a big gray area below the second text field.
>> Could you test the .ui patch I send to the list?
>
> I can not find any attachment of yours from this thread. Could you
> please fix the layout and commit?
>
> For this TextLayout panel, I think two textedit/browser can be
patch for listingsui.ui and textlayout.ui attached
(will be offline until sunday...)
Bo Peng wrote:
Index: src/frontends/qt4/ui/ListingsUi.ui
===
The patch can not be cleanly applied here... I guess you will have to
open designer
Index: src/frontends/qt4/ui/ListingsUi.ui
===
The patch can not be cleanly applied here... I guess you will have to
open designer and repeat what you have done again.
Sorry about the inconvenience.
Bo
Bo Peng wrote:
>> There is a big gray area below the second text field.
>> Could you test the .ui patch I send to the list?
>
> I can not find any attachment of yours from this thread. Could you
> please fix the layout and commit?
"reply all"
>
> For this TextLayout panel, I think two texte
There is a big gray area below the second text field.
Could you test the .ui patch I send to the list?
I can not find any attachment of yours from this thread. Could you
please fix the layout and commit?
For this TextLayout panel, I think two textedit/browser can be put
side by side to save som
Bo Peng wrote:
> On 5/9/07, Edwin Leuven <[EMAIL PROTECTED]> wrote:
>> layout of text layout in document settings is broken...
>
> What exactly is broken? The dialog is too small for two editboxes, but
> I can set parameters there.
>
> Bo
>
There is a big gray area below the second text field.
Here the insert is always centered and sometimes it is labeled as "ERT".
I just noticed and fixed it.
Centered is normal diaplyed listing. If you need inline listing, check
inline from the listings dialog.
Bo
On 5/9/07, Edwin Leuven <[EMAIL PROTECTED]> wrote:
layout of text layout in document settings is broken...
What exactly is broken? The dialog is too small for two editboxes, but
I can set parameters there.
Bo
Bo Peng wrote:
>> Please wait for a day and then you can commit.
>
> An update patch has been committed. lyx2lyx seems to work but I could
> not test it because of the armtex.sty problem. The dialogs are ugly
> but I can live with it. I am especially happy with the validation
> system which can
layout of text layout in document settings is broken...
Bo Peng wrote:
Please wait for a day and then you can commit.
An update patch has been committed. lyx2lyx seems to work but I could
not test it because of the armtex.sty problem. The dialogs are ugly
but I can live with it. I am especia
Please wait for a day and then you can commit.
An update patch has been committed. lyx2lyx seems to work but I could
not test it because of the armtex.sty problem. The dialogs are ugly
but I can live with it. I am especially happy with the validation
system which can actually help some listing
PROTECTED]
Sent: Wed 5/9/07 16:57
To: Leuven, E.
Subject: Re: [Final Patch] InsetListings ...
> and another one...
The first QTextBrowser is too big and I can not resize it to a small
size. Because it only displays error messages, I guess I actually need
a multi-line label with scroll box. At le
as in attached?
Yes. If I 'layout' the two editboxes in group box. The first box
resizes and I can not resize it back to a smaller size after
'layout'ing.
I guess I should choose two editboxes *and* the group box and layout
them, but the first editbox still resizes.
Bo
The question, basically, is why you're making use of getOptions. My
understanding was that getOptions and setOptions (and some other things)
were scheduled for removal because they're some kind of relic of an older
way in which insets interacted with parameters. (There are other routines
in the sa
as in attached?
-Original Message-
From: Bo Peng [mailto:[EMAIL PROTECTED]
Sent: Wed 5/9/07 16:23
To: Andre Poenitz
Cc: Peter Kümmel; LyX Devel List
Subject: Re: [Final Patch] InsetListings ...
> The groupbox itself needs a layout. If there's only one item in there
> (the l
The groupbox itself needs a layout. If there's only one item in there
(the lineedit) it doesn't really matter which kind of layout, but one is
needed...
1. create a new dialog
2. put a push button
3. put a group box
4. put a lineedit in group box
5. put another lineedit in group box
6. select t
On Tue, May 08, 2007 at 05:04:27PM -0500, Bo Peng wrote:
> >Starting with your ui file I get a design which seems ok when I click
> >1. in the QGroupBoxlayout->vertical (then I see the narrow band)
> >2. again layout->vertical on the empty space on the right of the QGroupBox
> >3. and change the si
Starting with your ui file I get a design which seems ok when I click
1. in the QGroupBoxlayout->vertical (then I see the narrow band)
2. again layout->vertical on the empty space on the right of the QGroupBox
3. and change the sizePolicy property of listingTB to expanding
This seems to work and
Bo Peng wrote:
>> +bool InsetListingsParams::fromEncodedString(string const & in)
>> +{
>> + // Decode string!
>> + // Do nothing because " was silently ignored.
>> + setParams(in);
>> +}
>>
>> msvc needs a return value.
>
> Thanks. I will correct that. bool was used in many plac
+bool InsetListingsParams::fromEncodedString(string const & in)
+{
+ // Decode string!
+ // Do nothing because " was silently ignored.
+ setParams(in);
+}
msvc needs a return value.
Thanks. I will correct that. bool was used in many places to see if a
parameter string is corre
Bo Peng wrote:
> Dear all,
>
> I have spent another two days on the InsetListings patch, trying to
> make the GUI more usable. What I get is a validation system that
> reports to QInclude, QListings and QDocument exactly what is wrong
> with the params string (through exception). With the attached
José Matos wrote:
> On Tuesday 08 May 2007 21:51:29 Bo Peng wrote:
>> With this validation system in place, I will stop working on this
>> feature until I get an OK to proceed.
>
> You have an OK to proceed, but I would like to hear more feedback from the
> list to the technical details of the
On Tuesday 08 May 2007 21:51:29 Bo Peng wrote:
> With this validation system in place, I will stop working on this
> feature until I get an OK to proceed.
You have an OK to proceed, but I would like to hear more feedback from the
list to the technical details of the patches.
Please wait for
On Mon, 7 May 2007, Bo Peng wrote:
Ok. I thought it was only one other person that would need to open/edit
the .lyx-file.
A few people will edit the file but the file will be released to public.
I do not expect many (any?) people to open the file with lyx because the
PDF version will also
Ok. I thought it was only one other person that would need to open/edit
the .lyx-file.
A few people will edit the file but the file will be released to
public. I do not expect many (any?) people to open the file with lyx
because the PDF version will also be released. It does not make sense
to re
On Mon, 7 May 2007, Bo Peng wrote:
> The file format problem would not be solved by a branch.
Why not? (I don't understand)
Because the reference manual I produce can not be opened by others
except for a few people in my own group GUI, validations stuff are
superficial, file format is
> The file format problem would not be solved by a branch.
Why not? (I don't understand)
Because the reference manual I produce can not be opened by others
except for a few people in my own group GUI, validations stuff are
superficial, file format is the key of this debate.
Bo
On Mon, 7 May 2007, Bo Peng wrote:
Could Bo and his colleague work using a LyX that's compiled from a branch,
where the split from trunk is done just after 1.5.0 has been released?
The file format problem would not be solved by a branch.
Why not? (I don't understand) The way I envision it
Could Bo and his colleague work using a LyX that's compiled from a branch,
where the split from trunk is done just after 1.5.0 has been released?
The file format problem would not be solved by a branch. All I need is
a placeholder in 1.5.0 to read \inset listings, \lstinputlisting and
\lstparam
On Mon, 7 May 2007, Jean-Marc Lasgouttes wrote:
Jürgen> But apart from that (and independent from the specific patch and
Jürgen> feature), I just think it's long overdue to stop putting things
Jürgen> in 1.5 that are not strictly fixing bugs.
+10
Could Bo and his colleague work using a LyX
Bo Peng wrote:
>> > 130 parameters is sheer madness. :-)
>>
>> +1, sorry Bo...
>
> What are you sorry for? I am not going to validate all 130 parameters
> right now, and there will be the GUI designer's decision how to choose
> and present the most important parameters, and leave others may be t
Bo> This is what I tried to do at first. However, in lyx, every line
Bo> starts a new paragraph and you will get an extra newline between
Bo> your program code. This is hard-coded to lyx and I do not see a
Bo> good solution to this problem.
Adding a special layout flag to avoid this would be less
> 130 parameters is sheer madness. :-)
+1, sorry Bo...
What are you sorry for? I am not going to validate all 130 parameters
right now, and there will be the GUI designer's decision how to choose
and present the most important parameters, and leave others may be to
a simple texteditor.
Right
On Mon, 07 May 2007 11:06:10 +0100
José Matos <[EMAIL PROTECTED]> wrote:
> On Monday 07 May 2007 06:41:56 Bo Peng wrote:
> > > It is a lot of work to validate ~ 130 parameters!!
> >
> > The validators are there (in InsetListingsParams.h/cpp now, class
> > parValidator) and I (or someone with some
On Monday 07 May 2007 06:41:56 Bo Peng wrote:
> > It is a lot of work to validate ~ 130 parameters!!
>
> The validators are there (in InsetListingsParams.h/cpp now, class
> parValidator) and I (or someone with some time to spare?) will add
130 parameters is sheer madness. :-)
If necessary choo
Bo Peng wrote:
> 1. validation: wrong arguments will be passed to latex, If Abdel can
> implement a property editor GUI, validation can do done over there.
This is important.
But don't count on me in the next weeks. I won't have time, sorry.
Abdel.
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> i only took a look at the result (not the code), and it made me
>> wonder what exactly is gained by this?
Bo> A non-ERT way to use listings package.
Hmm
>> wouldn't you want to set "code listing" or something like that in
>> the layout box an
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> The risk it that we implement it in a way that is not
Jürgen> thoroughly pondered (because of lacking time). Georg already
Jürgen> pointed out that he sees several things that have to be
Jürgen> thought about carefully with t
> 1. validation: wrong arguments will be passed to latex, If Abdel can
> implement a property editor GUI, validation can do done over there.
This is important.
It is a lot of work to validate ~ 130 parameters!! I guess I can do
that before 1.5.0 because validation is arguably the most importa
On Sunday 06 May 2007 20:02:03 Bo Peng wrote:
> Two problems remains:
>
> 1. validation: wrong arguments will be passed to latex, If Abdel can
> implement a property editor GUI, validation can do done over there.
This is important.
> 2. option value with ". I quote params_ with "" in .lyx file,
On Sunday 06 May 2007 20:14:50 Bo Peng wrote:
> Anyway, I agree with Georg to put lstinputlisting there, although
> JMarc seems to prefer 'external material'.
A long term goal, that dates back to inset external creation, is the merging
of external inset with graphics and with include insets.
So
Whether or not InsetListings should be
collapsible is open to discussion.
My reasons for using InsetCollapsable are that program listings
1. can be long (maybe over several pages) so CLOSE mode can be usable.
2. can be short or inlined (lstinline) so INLINE mode can be usable.
3. can float.
i only took a look at the result (not the code), and it made me wonder
what exactly is gained by this?
A non-ERT way to use listings package.
implementation wise i find it strange to have code in a collapseable
inset (i also tried ERT, as in attached, and found that this is pretty
similar ui w
Attached please find a much improved InsetListings patch. The
implementation can now be reviewed...
I will explain more about the params issue.
Herbert's patch has a big dialog which handles around 10 commonly used
parameters. I tried but I was not able to port it to qt4, due to my
limited know
On technical grounds I think that another option is to have:
language=Python
float
I will explain what I have done in another thread.
Bo
On Saturday 05 May 2007 16:43:47 Bo Peng wrote:
> The only solution I can think of is the HTML way, where special
> characters are encoded in &1023; etc for storage and transportation.
> Does anyone know how to implement this?
On technical grounds I think that another option is to have:
language=
Bo Peng wrote:
Attached please find a much improved InsetListings patch. The
implementation can now be reviewed...
i only took a look at the result (not the code), and it made me wonder
what exactly is gained by this?
some impressions:
implementation wise i find it strange to have code in a
I propose a deal ;-) :
You promise to fix all remaining issues (if any) WRT your features and
then this feature can go in (AFAIAC of course). Straight out of my head,
here are some bugs related to your work:
If you promise to change my simple QEditBox to property editors (like
what qt designer
Bo Peng wrote:
> Attached please find a much improved InsetListings patch. The
> implementation can now be reviewed...
>
> Changes:
>
> Better organized InsetListingsParams functions
> Autotools support
> InsetListings now derives from InsetERT
> Use LISTINS_CODE
> Code cleaning
> and more...
l
Bo Peng wrote:
Dear all,
Attached please find a much improved InsetListings patch. The
implementation can now be reviewed...
Changes:
Better organized InsetListingsParams functions
Autotools support
InsetListings now derives from InsetERT
Use LISTINS_CODE
Code cleaning
and more...
Looks much
The only problem I can see with file format is that listings can have
a large number of parameters and lexer may not be able to read the
whole string. Right now, I save/load/transport parameter strings like
language=Python,float
in the form of
language=Python!float
but ! may (I am not sure) be
> The risk it that we implement it in a way that is not thoroughly pondered
> (because of lacking time). Georg already pointed out that he sees several
> things that have to be thought about carefully with the listings
> implementation.
It would be much easier to 'ponder' with this patch. Please
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
>> If you are not a developer and you need listings you throw away LyX,
>
Ah, I forgot, one could use ERTs.
> How do you substantiate that statement? What data do you have about users
> that
> have thrown away LyX for exactly that reason?
>
Ha
Peter Kümmel wrote:
> If you are not a developer and you need listings you throw away LyX,
How do you substantiate that statement? What data do you have about users that
have thrown away LyX for exactly that reason?
> and when you are developer but you don't need it then you are not interested
Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
>> I agree with Bo that we shouldn't wait until 1.6
>> with the support of listings, it's so essential
>> when writing documents with code listings.
>>
>> Especially many of the LyX users are familiarly with
>> a programming language and will maybe us
Peter Kümmel wrote:
> I agree with Bo that we shouldn't wait until 1.6
> with the support of listings, it's so essential
> when writing documents with code listings.
>
> Especially many of the LyX users are familiarly with
> a programming language and will maybe use listings
> for their documents.
I agree with Bo that we shouldn't wait until 1.6
with the support of listings, it's so essential
when writing documents with code listings.
Especially many of the LyX users are familiarly with
a programming language and will maybe use listings
for their documents.
When we put in Bo's patch now we
61 matches
Mail list logo
