On Tuesday, 28 May 2019 12.28.29 WEST Pavel Sanda wrote:
> Fine with me. P
+1
--
José Abílio
On Mon, May 27, 2019 at 11:41:48PM -0400, Richard Kimberly Heck wrote:
> I propose the attached changes to the View menu for 2.4. The big
> advantage, to my mind, is much more sensible shortcuts. The downside
> would be that we make such a change, of course, but I think it would be
> worth it. I've
Am 15.02.2015 um 17:21 schrieb Richard Heck:
I think "PDF (E-book)" would be misleading. It suggests something more
is going on than just a lower resolution.
OK. I changed it now to "lower resolution"
(since the resolution is not really low (that would be 72dpi according
to most info in the w
Richard Heck wrote:
> I think "PDF (E-book)" would be misleading. It suggests something more
> is going on than just a lower resolution.
+1
Another disadvantage is that users might think that this format is only
usable for ebooks, but this is not true.
Georg
On 02/15/2015 10:52 AM, Uwe Stöhr wrote:
Am 15.02.2015 um 11:26 schrieb Georg Baum:
We could also name it "PDF (low resolution)", but this is much
longer, and I
thought the more accurate description would be better. The
overcrowded menu
is indeed not nice, so I am fine wth the current status a
Am 15.02.2015 um 11:26 schrieb Georg Baum:
We could also name it "PDF (low resolution)", but this is much longer, and I
thought the more accurate description would be better. The overcrowded menu
is indeed not nice, so I am fine wth the current status as well. Richard, I
guess this should also b
Uwe Stöhr wrote:
> However, the export menu is now overcrowded in my opinion. The 150 dpi-
> converter has a very limited target audience and should therefore not be
> by default in the main export menu.
I put it there because the cropped pdf was already in the export menu (which
is IMHO needed
On 02/14/2015 09:29 PM, Uwe Stöhr wrote:
Am 08.02.2015 um 11:46 schrieb Georg Baum:
I think the reason why it does not exist already is that nobody asked
for
such an option yet.
Hi Georg,
thanks for the implementation.
However, the export menu is now overcrowded in my opinion. The 150
dpi-
Am 08.02.2015 um 11:46 schrieb Georg Baum:
I think the reason why it does not exist already is that nobody asked for
such an option yet.
Hi Georg,
thanks for the implementation.
However, the export menu is now overcrowded in my opinion. The 150 dpi-
converter has a very limited target audien
Liviu Andronic writes:
> On Thu, Feb 12, 2015 at 9:41 AM, Rainer M Krug wrote:
>> Liviu Andronic writes:
>>
>>> On Tue, Feb 10, 2015 at 12:04 AM, James wrote:
>
On a similar note, AFAIK most of the size reduction comes from Ghostscript
reducing the size of the raster images
On Thu, Feb 12, 2015 at 9:41 AM, Rainer M Krug wrote:
> Liviu Andronic writes:
>
>> On Tue, Feb 10, 2015 at 12:04 AM, James wrote:
>>>
>>> On a similar note, AFAIK most of the size reduction comes from Ghostscript
>>> reducing the size of the raster images and those with raster components.
Liviu Andronic writes:
> On Tue, Feb 10, 2015 at 12:04 AM, James wrote:
>>>
>>
>> On a similar note, AFAIK most of the size reduction comes from Ghostscript
>> reducing the size of the raster images and those with raster components. The
>> next level of usability (beyond using a converter on a w
James wrote:
> As a user and not a developer, it would be very handy to have the
> description of how to add a converter to reduce the PDF output size in a
> wiki entry. Yesterday I made a recommendation to three people to add the
> converters. I pointed them to the lyx-devel list, but none were a
Liviu Andronic wrote:
> Agreed. I would only propose that we provide two additional
> converters: one for TeX fonts and other for non-TeX fonts. Since this
> would be for draft, non-final documents, it really should not matter
> less which exact converter of each type is being used. But some users
On Tue, Feb 10, 2015 at 12:04 AM, James wrote:
>>
>
> On a similar note, AFAIK most of the size reduction comes from Ghostscript
> reducing the size of the raster images and those with raster components. The
> next level of usability (beyond using a converter on a whole document) would
> be to hav
>
>
>
On a similar note, AFAIK most of the size reduction comes from Ghostscript
reducing the size of the raster images and those with raster components.
The next level of usability (beyond using a converter on a whole document)
would be to have an option within the figure float setting or graphic
On Tue, Feb 10, 2015 at 8:49 AM, Liviu Andronic
wrote:
>
> Agreed. I would only propose that we provide two additional
> converters: one for TeX fonts and other for non-TeX fonts. Since this
> would be for draft, non-final documents, it really should not matter
> less which exact converter of eac
On Mon, Feb 9, 2015 at 9:45 PM, Georg Baum
wrote:
> Liviu Andronic wrote:
>
>> Actually my observation would be different, and IMO this is a somewhat
>> oft-requested feature:
>> http://comments.gmane.org/gmane.editors.lyx.devel/127499
>> http://comments.gmane.org/gmane.editors.lyx.general/73209
>
Liviu Andronic wrote:
> Actually my observation would be different, and IMO this is a somewhat
> oft-requested feature:
> http://comments.gmane.org/gmane.editors.lyx.devel/127499
> http://comments.gmane.org/gmane.editors.lyx.general/73209
Sorry, it looks I am suffering from the selective memory d
On 02/08/2015 06:08 AM, Liviu Andronic wrote:
Hi Georg,
On Sun, Feb 8, 2015 at 11:46 AM, Georg Baum
wrote:
James wrote:
It would be great to see a button or Document menu item that gave an
option to view/compile in a reduced size by with ghostscript and setting
the -dPDFSETTINGS
switch to
Hi Georg,
On Sun, Feb 8, 2015 at 11:46 AM, Georg Baum
wrote:
> James wrote:
>
>> It would be great to see a button or Document menu item that gave an
>> option to view/compile in a reduced size by with ghostscript and setting
>> the -dPDFSETTINGS
>> switch to one of the following
>> /screen (72d
James wrote:
> It would be great to see a button or Document menu item that gave an
> option to view/compile in a reduced size by with ghostscript and setting
> the -dPDFSETTINGS
> switch to one of the following
> /screen (72dpi), /ebook (150dpi), /printer (300dpi), /prepress (300dpi),
> /default
On Fri, May 23, 2014 at 6:01 PM, Richard Heck wrote:
> On 05/23/2014 05:49 PM, Scott Kostyshak wrote:
>>>
>>> Which it should as a result of
>>> resetting the
>>> cursor since e.g. the TOC needs updating to reflect the new position.
>>> Indeed, not all dialogs
>>> need updating, but we don't have
On 05/23/2014 05:49 PM, Scott Kostyshak wrote:
Which it should as a result of
resetting the
cursor since e.g. the TOC needs updating to reflect the new position.
Indeed, not all dialogs
need updating, but we don't have such fine-grained information.
Is there an example of a dialog that needs to
On Fri, May 23, 2014 at 5:24 PM, Richard Heck wrote:
>> Inside of ViewSourceWidget::updateView is it possible to tell whether
>> it was called because of a cursor movement or because of an
>> insertion/edit?
>
>
> I don't think so. You'd need to get this information during the dispatch, I
> think
On 05/23/2014 05:11 PM, Scott Kostyshak wrote:
When "Automatic update" is checked, the source view updates whenever I
move the cursor. I think it would be nice if this did not happen when
moving the cursor within the same paragraph (when "Current paragraph"
is selected), unless we plan on trackin
On 10/29/2011 03:57 PM, Vincent van Ravesteijn wrote:
> Op 29-10-2011 21:54, Richard Heck schreef:
>> On 10/29/2011 03:48 PM, Vincent van Ravesteijn wrote:
>>> Op 29-10-2011 21:11, Richard Heck schreef:
I'm seeing PNG and EPS as output format options in the source view
window. That seems
Op 29-10-2011 21:54, Richard Heck schreef:
On 10/29/2011 03:48 PM, Vincent van Ravesteijn wrote:
Op 29-10-2011 21:11, Richard Heck schreef:
I'm seeing PNG and EPS as output format options in the source view
window. That seems wrong. Would it be better here just to list the
possible backends? i.
On 10/29/2011 03:48 PM, Vincent van Ravesteijn wrote:
> Op 29-10-2011 21:11, Richard Heck schreef:
>> I'm seeing PNG and EPS as output format options in the source view
>> window. That seems wrong. Would it be better here just to list the
>> possible backends? i.e., the formats LyX can output direc
Op 29-10-2011 21:11, Richard Heck schreef:
I'm seeing PNG and EPS as output format options in the source view
window. That seems wrong. Would it be better here just to list the
possible backends? i.e., the formats LyX can output directly?
Richard
I don't see PNG and EPS.
By the way, the whol
Pavel Sanda wrote:
> what about putting update button next to automatic update?
> we spend quite some time to make this dialog resizable to
> as small vertizal size as possible.
Personally, I find horizontal space much more valuable. The dialog still is
pretty narrow (vertically) with the new wid
Jürgen Spitzmüller wrote:
> Opinions?
what about putting update button next to automatic update?
we spend quite some time to make this dialog resizable to
as small vertizal size as possible.
pavel
Jürgen Spitzmüller wrote:
> I come back to this. Attached is a reworked version of the view source
> part. I have added a cache for the default flavor, since it is overkill to
> recheck for the flavor on each key stroke.
And here comes a further addition: this adds a combo with the available outpu
On 12/04/2010 11:03 AM, Jürgen Spitzmüller wrote:
Richard Heck wrote:
My only question is one I think JMarc asked earlier, namely, whether we
want to provide some
mechanism for indicating flavor in some config file, rather than trying
to guess it.
We do not guess it. I introduced a converter fl
Richard Heck wrote:
> My only question is one I think JMarc asked earlier, namely, whether we
> want to provide some
> mechanism for indicating flavor in some config file, rather than trying
> to guess it.
We do not guess it. I introduced a converter flag that defines the (latex)
flavor, and we
On 12/04/2010 09:54 AM, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
A patch along this line is attached. We still have to hardcode xhtml,
since there's no dedicated converter where we could derive a xhtml flag
from.
I committed the backend=flavor part, since
Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > A patch along this line is attached. We still have to hardcode xhtml,
> > since there's no dedicated converter where we could derive a xhtml flag
> > from.
>
> I committed the backend=flavor part, since this is a step forward anyway
> and
Le 30/11/2010 10:50, Jürgen Spitzmüller a écrit :
Jürgen Spitzmüller wrote:
A patch along this line is attached. We still have to hardcode xhtml,
since there's no dedicated converter where we could derive a xhtml flag
from.
I committed the backend=flavor part, since this is a step forward any
Jürgen Spitzmüller wrote:
> A patch along this line is attached. We still have to hardcode xhtml,
> since there's no dedicated converter where we could derive a xhtml flag
> from.
I committed the backend=flavor part, since this is a step forward anyway and
removes some bad hardcoding.
Jürgen
Jean-Marc Lasgouttes wrote:
> Second try, now that I read the code: change the converter flag "latex" to
> take the form "latex=xetex" or whatever to indicate the latex flavor that
> we want. "latex" will be equivalent to "latex=latex".
>
> With this, the information does not need to be hardcoded
> this is interesting idea even for other backends like docbook
>
> pavel
>
AFAIK this already works for docbook.
Vincent
Le 24 nov. 2010 à 22:01, Jürgen Spitzmüller a écrit :
>> I do not understand why we need to do that since latex export requires
>> this information anyway. We just have to look at the first intermediate
>> step of the lyx->...->output converter chain.
>
> I cannot follow you.
Second try, now that
Jean-Marc Lasgouttes wrote:
> I do not understand why we need to do that since latex export requires
> this information anyway. We just have to look at the first intermediate
> step of the lyx->...->output converter chain.
I cannot follow you.
Jürgen
Le 24 nov. 2010 à 17:04, Jürgen Spitzmüller a écrit :
> Actually, I was just working on a patch that would take the default output
> format instead of just LaTeX or XeTeX for the source view. It would roughly
> look as follows (without XHTML and DocBook so far, but the direction should
> be clea
On 11/24/2010 11:04 AM, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
this is interesting idea even for other backends like docbook
Actually, I was just working on a patch that would take the default output
format instead of just LaTeX or XeTeX for the source view. It would roughly
look as foll
Pavel Sanda wrote:
> this is interesting idea even for other backends like docbook
Actually, I was just working on a patch that would take the default output
format instead of just LaTeX or XeTeX for the source view. It would roughly
look as follows (without XHTML and DocBook so far, but the di
Richard Heck wrote:
>
> How hard would it be to have View>Source output, say, HTML, if that is the
> default view format for the document?
this is interesting idea even for other backends like docbook
pavel
On 2/2/10, 0 wrote:
> I am a LyX user and still would appreciate any help on my problem.
>
Exporting LyX/LaTeX to .doc/.odt/.rtf and the like can be problematic.
You can search the wiki and the archives for various experiences.
Liviu
PM
Subject: RE: "View - OpenDocument" command produces empty output - help!
> Yes, dvi and pdf work fine for me. But I want
OpenDocument because
> I'm sending the file to another person and want
him to be able to edit the file.
I know, but
don't send your answer SEVEN times ?!?
Vincent
> Yes, dvi and pdf work fine for me. But I want OpenDocument because
> I'm sending the file to another person and want him to be able to edit
the file.
I know, but don't send your answer SEVEN times ?!?
Vincent
: Tue, February 2, 2010 8:02:15 PM
Subject: RE: "View - OpenDocument" command produces empty output - help!
Don't use OpenDocument. Use dvi or pdf to preview.
Vincent
From: 0
To: lyx-devel@lists.lyx.org;
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 201
I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like
Bob to be able to edit this document.
- Original Message
From: Vincent van Ravesteijn - TNW
To: 0 ; lyx-devel@lists.lyx.org;
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 8:02:15 PM
Subject: RE:
I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like
Bob to be able to edit this document.
--- On Tue, 2/2/10, Vincent van Ravesteijn - TNW
wrote:
> From: Vincent van Ravesteijn - TNW
> Subject: RE: "View - OpenDocument" command produces empt
>[examples/splash.lyx] is the document which automatically opens when
user
>runs LyX first time after installation. The problem is that the "View -
>OpenDocument" command produces empty output for me. Please help!
Don't use OpenDocument. Use dvi or pdf to preview.
Vincent
Pavel Sanda wrote:
> >Then what happens if view/update is switched off?
>
> you mean by user? then nothing since the layout is driven by qsettings
> from that point.
OK.
Jürgen
Jürgen Spitzmüller wrote:
> Maybe "widen" is not the most transparent tag, I don't know ("samerow"?).
looks good.
> > or should we put view before extra instead after standard?
>
> Personally, I have it in the second row, before extra. But this means extra
> needs the tag, right?
exactly
>The
Pavel Sanda wrote:
> like this?
Looks like it. Great.
Maybe "widen" is not the most transparent tag, I don't know ("samerow"?).
> or should we put view before extra instead after standard?
Personally, I have it in the second row, before extra. But this means extra
needs the tag, right? Then wha
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > to sum it up - i change the toolbar very often so i asked about changing
> > the defaults either to off or to vertical position.
>
> I'd rather fix the cause (i.e., allow for multiple toolbars in a row).
like this? or should we put view before e
Abdelrazak Younes wrote:
>> no more qsettings! :) if they wont get restarted every other day and we
>> have it in
>> normal preferences then there was no need for this thread.
>>
>
> I don't understand this QSettings animosity. It's quite a fine class. Maybe
> the problem lies in our way to us
Pavel Sanda wrote:
> to sum it up - i change the toolbar very often so i asked about changing
> the defaults either to off or to vertical position.
I'd rather fix the cause (i.e., allow for multiple toolbars in a row).
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > no more qsettings! :) if they wont get restarted every other day and we
> > have it in normal preferences then there was no need for this thread.
>
> Still? I thought we fixed this.
we fixed some issues and added new ones. for example we have un
Pavel Sanda wrote:
Abdelrazak Younes wrote:
If you have the courage and willingness to do it, I suggest to kill this ui
file once and for all. We can either have sane hardcoded default or use a
QSettings based ini file.
no more qsettings! :) if they wont get restarted every other day
Pavel Sanda wrote:
> no more qsettings! :) if they wont get restarted every other day and we
> have it in normal preferences then there was no need for this thread.
Still? I thought we fixed this.
Jürgen
Jürgen Spitzmüller wrote:
>
> Yes. But that's not a big deal, is it?
i felt frustrated to do it again and again and again.
pavel
Abdelrazak Younes wrote:
> So your point is that we should change the default? Or maybe that we should
> create another tag in order to put two toolbars on the same row?
of course i'm talking about the defaults the whole time ;)
>
> If you have the courage and willingness to do it, I suggest to
> ... QSettings based ini file ...
QSettings roars its tail again..
>Abdel.
Vincent
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
you dont get it displayed as a third row??
No.
and you didn't se it manually, right?
Of course he did :-)
because default.ui says:
"view/update" "on,top"
and behaves like this here.
So your point
Pavel Sanda wrote:
> and you didn't se it manually, right?
Yes. But that's not a bug deal, is it?
> because default.ui says:
> "view/update" "on,top"
Yes, we should implement a way to position two toolbars in a row in the first
place.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > you dont get it displayed as a third row??
>
> No.
and you didn't se it manually, right?
because default.ui says:
"view/update" "on,top"
and behaves like this here.
pavel
Pavel Sanda wrote:
> you dont get it displayed as a third row??
No.
Jürgen
<>
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > while we are at ui flames... notebooks are becoming wider while height is
> > constant or even smaller in some cases - saving vertical space is more
> > important than horizontal one. i find myself constantly moving the
> > solitary view/update
Pavel Sanda wrote:
> while we are at ui flames... notebooks are becoming wider while height is
> constant or even smaller in some cases - saving vertical space is more
> important than horizontal one. i find myself constantly moving the
> solitary view/update toolbar somewhere else...
>
> what
Am 11.01.2010 13:18, schrieb Pavel Sanda:
hi,
while we are at ui flames... notebooks are becoming wider while height is
constant
or even smaller in some cases - saving vertical space is more important than
horizontal
one. i find myself constantly moving the solitary view/update toolbar somewh
rgheck schreef:
The crash comes when we try to access: cur->buffer():
This is bug #6388: www.lyx.og/trac/ticket/6388.
Vincent
Pavel Sanda wrote:
> i would let "View [Other formats]" to be "View (Other formats)"
> for better discernment from "View [format]".
OK.
> > > i still volunteer for adding the rc entry since
> > > clearly we are not able to agree what the good ui is.
> >
> >
> > No, please don't clutter the pref
Jürgen Spitzmüller wrote:
>I've done that. Please test.
i would let "View [Other formats]" to be "View (Other formats)"
for better discernment from "View [format]".
> > i still volunteer for adding the rc entry since
> > clearly we are not able to agree what the good ui is.
>
> No, please don't
Pavel Sanda wrote:
> > How about appending this to the entry then, as in "View [PDF
> > (pdflatex)]"?
>
> better than nothing.
I've done that. Please test.
> i still volunteer for adding the rc entry since
> clearly we are not able to agree what the good ui is.
No, please don't clutter the pr
Pavel Sanda wrote:
> i found another bug meanwhile - the other format in toolbar is not
> remembered through the sessions.
This is no bug. It is not supposed to do that (yet).
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > eyes need to see the 'pdflatex' string somewhere in the menu to get quick
> > orientation and better on a constant place with other formats.
>
> How about appending this to the entry then, as in "View [PDF (pdflatex)]"?
better than nothing. i sti
Pavel Sanda wrote:
> eyes need to see the 'pdflatex' string somewhere in the menu to get quick
> orientation and better on a constant place with other formats.
How about appending this to the entry then, as in "View [PDF (pdflatex)]"?
Jürgen
Jürgen Spitzmüller wrote:
> It would be a duplicate of UI entries. I'm not opposed, but it's certainly
> not
> good UI design.
eyes need to see the 'pdflatex' string somewhere in the menu to get quick
orientation and better on a constant place with other formats.
i propose this patch. it could
Pavel Sanda wrote:
> nice, i see it now. there is small issue - the small down-arrow in the icon
> appears only after first use. this is intended?
No.
> my basic question was a bit different though - would you be against the
> inclusion the default output format in the view submenu?
It would b
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > little bit of hijacking but anyway: the new formats machinery is kinda
> > confusing for me since i use and often switch between postscript and
> > pdf(latex) output. i can't use it directly from toolbar as it was till
> > now,
>
> Sure you can
Pavel Sanda wrote:
> little bit of hijacking but anyway: the new formats machinery is kinda
> confusing for me since i use and often switch between postscript and
> pdf(latex) output. i can't use it directly from toolbar as it was till
> now,
Sure you can. For instance, you can set the default
> This complaint comes from my collegues under Windows(XP) operating
> system. Whenever they want to view pdf/dvi/ps it takes sometime to see
> the output. Most of them are not patient enough to wait the output.
This is most probably due to the image formats they used. When you are using one of
On Sun, Jan 11, 2009 at 09:07:54AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > > Enrico Forestieri wrote:
> > > > Please try the attached patch. It works for me even with Qt 4.2.
> > > > The Source View window always opens at its minimum height.
> > >
> > > yes, that works here
Enrico Forestieri wrote:
> > Enrico Forestieri wrote:
> > > Please try the attached patch. It works for me even with Qt 4.2.
> > > The Source View window always opens at its minimum height.
> >
> > yes, that works here.
>
> Jürgen?
go ahead.
Jürgen
On Sat, Jan 10, 2009 at 07:38:56PM +0100, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > Please try the attached patch. It works for me even with Qt 4.2.
> > The Source View window always opens at its minimum height.
>
> yes, that works here.
Jürgen?
--
Enrico
Enrico Forestieri wrote:
> Please try the attached patch. It works for me even with Qt 4.2.
> The Source View window always opens at its minimum height.
yes, that works here.
pavel
On Sat, Jan 10, 2009 at 06:31:42PM +0100, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > With Qt 4.4 I am still able to reduce the height such that only about
> > four lines of source are shown. With Qt 4.2 the height cannot be reduced
> > below about a dozen lines, but this happens with or wit
On Sat, Jan 10, 2009 at 06:15:56PM +0100, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Enrico Forestieri wrote:
> > > Using Qt 4.2, the View Source window is split such that only about 1/3
> > > of the full width is used for displaying the source (see the attached
>
> :( its nightmare to ge
Enrico Forestieri wrote:
> With Qt 4.4 I am still able to reduce the height such that only about
> four lines of source are shown. With Qt 4.2 the height cannot be reduced
> below about a dozen lines, but this happens with or without my patch.
which exactly version of qt? the recipy in the other m
Pavel Sanda wrote:
> Pavel Sanda wrote:
> > didn't fix the
>
> initialization
>
> > outliner/source w. bug and some code didn't get initialized after
> > launch. it also means that removing some code inside
> > ViewSourceWidget::ViewSourceWidget()
>
> i not sure now ViewSourceWidget::ViewS
Pavel Sanda wrote:
> didn't fix the
initialization
> outliner/source w. bug and some code didn't get initialized after
> launch. it also means that removing some code inside
> ViewSourceWidget::ViewSourceWidget()
i not sure now ViewSourceWidget::ViewSourceWidget() was the routine skipped.
Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Using Qt 4.2, the View Source window is split such that only about 1/3
> > of the full width is used for displaying the source (see the attached
:( its nightmare to get this dialog right.
> > without-patch.png). The attached patch corrects
On Sat, Jan 10, 2009 at 05:19:45PM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Using Qt 4.2, the View Source window is split such that only about 1/3
> > of the full width is used for displaying the source (see the attached
> > without-patch.png). The attached patch corrects th
Enrico Forestieri wrote:
> Using Qt 4.2, the View Source window is split such that only about 1/3
> of the full width is used for displaying the source (see the attached
> without-patch.png). The attached patch corrects this (with-patch.png).
> I verified that later versions of Qt are not affected
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Hi!
Starting quite recently (within the last two weeks?) the view source
and outliner widgets are open when LyX starts;
Only the first time. Afterwards, if session handling is enabled, LyX
will memorize the last window state, including toolbars
Dov Feldstern wrote:
Hi!
Starting quite recently (within the last two weeks?) the view source
and outliner widgets are open when LyX starts;
Only the first time. Afterwards, if session handling is enabled, LyX
will memorize the last window state, including toolbars and dock widgets
visibil
[EMAIL PROTECTED] wrote:
Did you intend to write 'single site'? (It's still one site, regardless
of the number of modes or views)
I mean a single mode.
Joost
1 - 100 of 206 matches
Mail list logo
