headers
christian.ridderstrom | 1 Aug 2007 01:04
Picon

Re: Layout question

On Mon, 30 Jul 2007, Paul A. Rubin wrote:

> christian.ridderstrom@... wrote:
>
>>  As a side note, it's perfectly possible to add an enhancement request to
>>  bugzilla, post a tweaked layout to bugzilla, and then refer to the tweaked
>>  layout in bugzilla from within a wiki page. Not sure if it helps, but it
>>  will keep the tweaked layout together with the enhancement request.
>
> I went the opposite direction -- posted the layouts on the wiki and then 
> put a link to the wiki page in the bugzilla request.  Probably just as 
> well I took that route; I subsequently found a bug in my layouts (no 
> doubt the first of many), and uploaded modified files to the wiki. Going 
> the other way, I'd have to both upload the changes to bugzilla and then 
> correct the link on the wiki.  At my age, remembering to do two things 
> is pushing my luck.

Your approach is valid, but somewhat unsafe as others may alter your 
layout with no reasonable trace. Yes, this is a drawback with the current 
system, but difficult to do something about.

This is also why we should avoid placing "official" files _inside_ the 
wiki - more or less everybody can upload a modifed versione.

/C
  >
> Cheers,
> Paul
>
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Darren Freeman | 1 Aug 2007 03:43
Picon
Picon

Re: 1.5.0 "slowness"

On Tue, 2007-07-31 at 18:12 +0200, Andre Poenitz wrote:
> On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote:
> > On Mon, 2007-07-30 at 22:41 -0600, Bob Lounsbury wrote:
> > > That's strange. I have an Athlon XP 2000+ with 1GB of RAM, and I have
> > > not noticed any slowness at all. I wonder if it has anything to do
> > > with the graphics card. This computer has an ATI 9800 graphics card,
> > > which is a very nice card. With my iBook I had a lot of slowness until
> > 
> > I have a Radeon 9200SE.
> > 
> > It is certainly using DRI at 24bpp.
> > 
> > I can't test the X settings hypothesis right now as I have a lot of
> > unsaved work open. Sounds likely though!
> 
> You can start new X servers on display :1, :2 etc...

Hadn't thought of that :) It's trivial on OpenSUSE 10.2 or Mandrake
10.x..

I tried that and couldn't find a clear improvement with DRI off and 16
bit. It would be better to try this on a single server though in case
there is some interaction with the already running KDE or Qt.

Have fun,
Darren
Permalink | Reply | 0 comments |
headers
Darren Freeman | 1 Aug 2007 03:58
Picon
Picon

Re: 1.5.0 "slowness"

On Tue, 2007-07-31 at 00:00 +0300, Martin Vermeer wrote:
> ...and more importantly, you just confirmed my diagnosis of
> the problem. There is something in qt, or LyX's use of qt,
> that responds very badly to DRI both being turned on and
> practically unusable.

Could all who are interested in this bug/thread please consider the
following "bug" which I think is related to why LyX is much slower on
figure floats:

http://bugzilla.lyx.org/show_bug.cgi?id=4002

"The figure float box is roughly the full width of the window, but in
fact it is
changing a small amount with every keypress. This causes the figures to move
because they are in a centred paragraph."

I'm not keeping up with what X with and without DRI are doing. With DRI, perhaps it's
supposed to locally blit from one place to another. However, who knows how good or bad the s/w
implementation is, it might have been faster to send it again from the source buffer.

Could the 16/24 bit issue be related to a format conversion between LyX/Qt4 and the X display, which
is skipped in one case but not the other?

Have fun,
Darren
Permalink | Reply | 4 comments |
headers
Paul A. Rubin | 1 Aug 2007 04:47
Picon
Favicon
Gravatar

Re: Layout question

christian.ridderstrom@... wrote:

> 
> Your approach is valid, but somewhat unsafe as others may alter your 
> layout with no reasonable trace. Yes, this is a drawback with the 
> current system, but difficult to do something about.

Well, if you're worrying about there being untrustworthy LyXers out 
there, I'm probably the least trustworthy of the lot, so my files should 
be safe.  ;-)

I see your point, though.  Layout files seem an unlikely target for the 
ill-intentioned, but it's possible some well-intentioned but perhaps 
misguided soul might modify the layouts and upload the new ones over the 
ones I posted.  If so, I expect it will be caught when the screaming 
starts on the user list.
> 
> This is also why we should avoid placing "official" files _inside_ the 
> wiki - more or less everybody can upload a modifed versione.

That makes sense, unless you can create an upload area readable by all 
but writable only by the developers.  As far as my tweaked layouts go, 
they won't be official until Juergen folds them into a subsequent 
release, at which point the wiki copies will be irrelevant.

There's been some comment on the user list about the desirability of 
having more people share layouts and such.  I had thought the wiki would 
be the ideal place for this.  It doesn't seem practical to use bugzilla 
to hold the files in general, so if not the wiki, then where?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bo Peng | 1 Aug 2007 04:49
Picon

Re: Compress file corrupted

I just compiled lyx against boost 1.34.1. Unfortunately, the problem
persists. So, unless someone can write to boost-devel, and be advised
with the correct way to write/build boost::iostreams under windows, we
have to revert to gzstreams for 1.5.1.

Bo
Permalink | Reply | 2 comments |
headers
Richard Heck | 1 Aug 2007 06:19
Favicon

[PATCH-updated] Bug 3676--Citation Bug

Andre Poenitz wrote:
> On Tue, Jul 31, 2007 at 03:00:34PM -0400, Richard Heck wrote:
>   
>> Index: src/Buffer.h
>> ===================================================================
>> --- src/Buffer.h	(revision 19264)
>> +++ src/Buffer.h	(working copy)
>>  <at>  <at>  -13,7 +13,11  <at>  <at> 
>>  #define BUFFER_H
>>  
>>  #include "DocIterator.h"
>> +#include "ErrorList.h"
>> +#include "InsetList.h"
>>  
>> +#include "frontends/controllers/frontend_helpers.h"
>>     
> Why that? Including stuff from frontends/ in src/ is wrong in theory.
>   
Yes, I agree. This is needed, IIRC (I did this a while ago), for certain 
constants, e.g.:
    static const docstring 
TheBibliographyRef(from_ascii("TheBibliographyRef"));
which was in frontends/controllers/frontend_helpers.cpp and which I've 
moved (in effect) to the header.

There is a lot of BibTeX-related stuff in frontends/controllers/. I 
think most of that should be elsewhere. I think the whole biblio 
namespace should be moved, probably into src/Biblio.{h,cpp}, or 
something similar. But I guess I thought I should address this first 
within the existing structure and save the clean-up for later. If you
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jürgen Spitzmüller | 1 Aug 2007 07:39
Picon
Favicon

Re: [PATCH] fix configuration with pkgconfig on the mac

Jean-Marc Lasgouttes wrote:
> José, Juergen, can I commit it (trunk and branch)?

Yes.

Jürgen
Permalink | Reply | 1 comment |
headers
Jürgen Spitzmüller | 1 Aug 2007 07:45
Picon
Favicon

Re: [PATCH] Re: Current svn: Crash with pdfsync

Jean-Marc Lasgouttes wrote:
> José, Jürgen, can I apply to trunk and branch. It is truly trivial.

OK.

Jürgen
Permalink | Reply | 1 comment |
headers
Jürgen Spitzmüller | 1 Aug 2007 07:51
Picon
Favicon

Re: [PATCH-update] Bug 2876: Mark modified files in View Menu

Richard Heck wrote:
> This patch is now updated to current trunk. Jurgen?

If it's well tested (which I believe it is), this can go in branch and trunk. 
But please wait with branch until the compression issue is sorted out.

BTW as I wrote in bugzilla it would be nice if the tabs also reflected the 
buffer dirtyness, but this is a separate issue.

Jürgen
Permalink | Reply | 0 comments |
headers
Jürgen Spitzmüller | 1 Aug 2007 07:53
Picon
Favicon

Re: [PATCH-updated] Bug 2840: Save all modified files

Richard Heck wrote:
> Here's this patch updated to the current trunk. Jurgen?

Same as for bug 2840: If it's well tested, this can go in branch and trunk. 
But please wait with branch until the compression issue is sorted out.

Jürgen
Permalink | Reply | 0 comments |

Gmane