> a LyX file is supposed to be modified only by LyX, no
It can be modified by 'svn update', 'vim' and any other text editors.
But I agree with you that this feature may not be the best one to work
on right now.
Bo
> It is much eqsier to keep them somewhat syncronized while we can.
I do not think so. merging everything from 1.5.3 to 1.6.x needs only
one command. Given the frequency of crashes I am getting now, locking
1.6.x till 1.5.3 is reasonable.
Bo
> Do you really believe any locking will be possible once Bromarv is
> started? As usual, there will be a flurry of activity and some
> breakage on the trunk.
That would be unfortunate. You guys should just have fun there, and
avoid breaking the trunk after a dozen beers. :-)
Bo
On 8/7/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> > Bo, I think building gettext with scons is broken now. Could you fix
> > it? It is difficult to fix blindly.
>
> OK.
Done. (It is really easy.)
Note that scons tries to use system gettext first. With Joost's
windows
I filed this bug because I would like to have a better way to reload
externally modified .lyx file. Currently, one has to close and reopen
the file, or make the buffer dirty to use File->revert.
A long discussion about vim or emacs-like 'automatic reloading'
feature was fruitless, so I propose the
> Sorry dude but I beat you to it :)
>
> http://bugzilla.lyx.org/show_bug.cgi?id=3766
I am happy that I am fixing two bugs. :-)
I had a look at your bug report and test-ran kwrite. It behaves the
same as gvim in that it checks if the file is modified when it gets
focus. It also uses name File->Re
> This command is traditionally called Revert. I checked in some random
> programs: Adobe Photoshop, the Gimp, Mathematica, Picassa.
'Reload' directly tells the user what will happen (the disk file will
be reloaded), while Revert tells the user the end effect (all changes
will be lost). I like rel
On 8/8/07, Alfredo Braunstein <[EMAIL PROTECTED]> wrote:
> Is this the right time for this patch?
Using a vector and remove count in class TexRow() simplify the code a
lot, but this makes me wonder why a list was used in the first place.
Is there a lot of insertion going on?
Bo
> As I know that it is easier stopping an hurricane than you,
Really? I am the best example of listening to others in this list. :-)
> and it
> happens that I like your patch because it is not intrusive, you
> have my ok. I really don't care about revert or reload.
How about "revert to saved". T
> All this is OK. I think I would have preferred a time-based solution
> rather than a crc based (especially since lyx::sum seems to be broken
> on windows http://bugzilla.lyx.org/show_bug.cgi?id=3172).
I now see why I remembered that listings child document was not monitored ...
I think bug 3172
> Whatever. I only have a suggestion. There's already a delay when
> using the menu, so I am concerned that this delay will increase
> if you have to compute a checksum every time. Would it not be
> more efficient and equally effective storing the file time stamp?
I am not familiar with boost::fil
> But I agree I would really have preferred a time-based protection with
> a _real_ protection against editing externally modified files.
So you can take over this patch, or at least show me how to get the
filestamp of a file.
Bo
> FileMonitor.cpp uses fs::last_write_time and computes crc only if the
> time has changed.
Thank. This is helpful:
./src/support/FileMonitor.cpp: pimpl_->timestamp_ =
fs::last_write_time(pimpl_->filename_.toFilesystemEncoding());
Do you want the same approach here? (This means I need to save b
> Yes, I would be delighted :)
OK. Can I apply the attached?
Cheers,
Bo
Index: src/Buffer.h
===
--- src/Buffer.h (revision 19356)
+++ src/Buffer.h (working copy)
@@ -209,6 +209,8 @@
bool isBakClean() const;
///
bool isDepClean(
> if there are no objections i propose the following patch.
> ([[menu]] is added since there is no menu shortcut to distinguish
> it from other occurences and in other langueages there is possibility
> to add correct shortcut.)
I do not know how this [[menu]] thing will work. Is this a gettext or
> This is the most important thing, and a must IMO. If this check is
> implemented (and only relying on the checksum, not on the time stamp,
> because the accuracy of the latter is as low as 2 seconds on FAT) then no
> dataloss can happen.
I agree with this. Is there already a enhancement request
> > If setting the availability of the 'revert' option is too
> > time-consuming - how about giving up and having 'revert' always
> > available?
>
> This one could be the best option.
The latest patch already uses time stamp, which should be very fast.
Bo
> >
> >> On 8/8/07, Alfredo Braunstein <[EMAIL PROTECTED]>
> >> wrote:
> >>> Is this the right time for this patch?
>
> Is it?
Not exactly, because many are drunk at Bromarv, and the rest are
watching what they will do after they get drunk.
> What the... In any case I'll apply the thing as soon a
> Now I am curious, what new features and improvements are planned for LyX
> 1.6.0?
This has not been decided, and a developers meeting is going on at
Bromarv. Most likely, the lyx file format will be changed to XML (with
many benefits unseen to users); layouts, shortcuts will be easier to
use, a
> There are also lots of pending stuff, including:
>
> - Stefan's math-macros work
> - Abdel's 1 bv per buffer work (that may facilitate ui improvements like
> detachment of panels and so on)
> - nonblocking latex compilation
> - ...
I am aware of them. To avoid the development control problem we
I have updated 4114 in response to Georg's suggestion. With the
attached patch, lyx would ask for permission to overwrite a file when
the file is externally modified.
The rest of the patch is untouched. Note that it uses timestamp before
checksum so 'File->Revert to saved' should not cause any de
> I'd suggest to replace isExternallyModified by these two methods
>
> bool Buffer::isProbablyNotExternallyModified() const
> bool Buffer::isExternallyModified() const
> and use the latter for the overwrite check and the first one elsewhere.
I would prefer
/// whether or not disk file ha
> as in the attached patch.
The updated patch is attached.
Bo
Index: src/Buffer.h
===
--- src/Buffer.h (revision 19374)
+++ src/Buffer.h (working copy)
@@ -209,6 +209,10 @@
bool isBakClean() const;
///
bool isDepClean(std::stri
> > as in the attached patch. (The logic is a bit complicated, and I hope
> > I got it right. :-)
>
> It is right, but less easy to understand IMHO. If I read
>
> if (buffer->isProbablyNotExternallyModified())
> do something
>
> I know that the test is not 100% safe. If I read
>
> if (buffe
> Case 1:
> Case 2:
Thank you for testing!
The problem can be fixed by returning false for isExternallyModified()
when the file does not exist, but I think it is better to disable
File->Revert in this case. Otherwise, we will revert to an empty file,
after three message boxes:
1. are you sure yo
> Case 3:
>
> 1) lyx //server/dir/file.lyx
> 2) Externally modify //server/dir/file.lyx
> 3) Access menu
> 4) Wait for about 2 seconds before menu appears
Timestamp is used so the file menu should be rendered as fast as
before when the file is not changed. Considering that externally
change rarely
> Yes, it is special to LyX. But what would be wrong with naming the
> thing "program listing" in the include dialog? It seems clearer to me.
>
I am OK with this patch, just I did not know this lyx trick.
Bo
> That is ugly indeed, but you could use an enum instead of the bool and
> remove the default argument. That would also be quite self documenting. And
> could you please add the info about the 2 second FAT timestamp granularity
> to the documentation? In 6 months nobody will remember that anymore.
> > All done, the eighth version is attached.
>
> Great! Thanks for being patient.
Committed. Thanks for commenting on the patch.
Bo
> I think the stuff that Tommaso Cucinotta attached to
And if XML is being discussed, please consider ODF compatibility. I
have been convinced that it is unlikely that lyx can adopt ODF as it
is, but it would be good to learn something from the ODF design, and
keep our file format as close to ODF
> proposed patch solves it for english too. as Bo said ok, it just needs
> somebody to commit it.
Done because I think JMarc also OKed it.
Bo
> - Bug 3713 Keyword completion feature of lyx
>
> which I would also be very happy to see (this is what I actually set out
> to solve when I first joined the list, but then I got waylaid by the RTL
> stuff...).
This one is the third on my TODO list, after embedding and shortcut
dialog. I will b
> The main reason I raised this issue right now is just that I think that
> if the search is properly designed, it should be able to provide an
> internal API which would allow us to easily find all occurrences of a
> given prefix, which is a major requisite of a word-completion feature...
This is
> This might be fragile, unless you plan to add hooks into all the
> places that might enter/modify a word.
I think it is enough to enable this for plain text in InsetText and
InsetTablular, because indexing formula etc does not make sense. Then,
it can be narrowed down to
1. when a word is enter
> Bo --- your idea is interesting, I hadn't even considered such an
> option...
I discarded the scanning idea without a second thought because
scanning through a document can be tedious. The index database method,
if implemented correctly, has the potential to provide instant word
completion sugge
> IMHO it fixes this bug. Please let me know wether it has a chance to be
> applied.
Sorry that I did not follow this thread closely. Does this related to
the caption in listings bug? If this solves the spell checking
problem, can that latex-language trick be removed?
Bo
> Yes, but I have my doubt that it can be done really right. OTOH, one
> can implement the search-based method and switch to something else if
> it really does not work. You know: "premature optimization yada yada".
This does not matter. class WordMagic can certainly keep a pointer to
the buffer a
> >> I did make clean and make distclean, and reran configure, etc.
I do not use autotools, but maybe autogen.sh can help?
You might also want to try scons.
Bo
> I'd be happy to do so but have never used it. What do I do?
Install scons from www.scons.org, and type scons. You may want to read
INSTALL.scons. If under windows, also INSTALL.Win32. The good thing
about scons is that after the first run, you always run a single
command 'scons install'.
> I se
> It z*works really well and fixes a bunch of bugs
> related to loading of child documents. Try it!
Sorry that I do not know what you have done in this branch and I can
not merge it just because 'it fixes a bunch of bugs'. To test it out,
I have to at least know the bug numbers.
Anyway, there has
> I don't believe this. Last time they put everything upside down .-)
I just notice this, and I am not happy about it. I know Lars has been
working on XML for a long time, but he had never discussed this
feature with others. Maybe I have missed his emails, maybe I should
have kept an eye on his br
> Oh, bull. I cannot feel guilty of not discussing this with you when
> the discussion happend before you emerged on this list.
OK. I apologize.
> Feel free to ask questions, and start some discussion...
What are your design goals? What are the benefits? Where is your
format specification? How d
> Did you see my patch from last week, which starts solving these problems
> in listings? Let's continue this issue in that thread...
> (http://permalink.gmane.org/gmane.editors.lyx.devel/91323)
I saw that. But I did not comment because I am not familiar with
language handling.
Bo
Lars,
Thank you very much for your quick reply. My understanding is that you
intent to generate a home-made XML format that is close to our current
format, and you have mostly finished lyx.XML output, but not input and
lyx2lyx, and no lyx.XML -> other.XML converter has been done. XML
input and lyx
I am quite busy recently and have not been actively testing a few
patches that I should have looked at (middle button paste, latex_lang,
no spell checking etc). But I felt that I have to take a side in this
debate this time. Maybe surprisingly, I am at Lar's side.
I am not sure how many active dev
I am trying to fix scons, with r19490
g++ -o debug/common/support/Timeout.o -c -g -O -DQT_GUI_LIB
-DQT_SHARED -Idebug/common -Isrc -Isrc -Iboost -Idebug/intl
-I/home/bpeng/lyx-devel/qt422/include
-I/home/bpeng/lyx-devel/qt422/include
-I/home/bpeng/lyx-devel/qt422/include/QtCore
-I/home/bpeng/lyx-d
On 8/12/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> I am trying to fix scons, with r19490
>
Never mind, Fixed. scons is usable now. (r19491)
Bo
> > While I agree that 1.5.0 is far better than 1.4.x, it was mostly
> > unusable during development,
>
> That's not really true. It is mostly unstable during the unicode
> transition, that's all.
At least I know that mouse-hovering introduced numerous bugs that were
cleared at a very late stage.
On 8/13/07, Alfredo Braunstein <[EMAIL PROTECTED]> wrote:
> I wonder the reason for this kind of changes on trunk. It certainly makes
> compilation a bit difficult... ;-)
>
> +<<< .mine
> +#include "BufferParams.h"
> +===
> #include "Counters.h"
> +>>> .r19497
Isn't this the result of
> Commited. If there are no problems with the new feature in the next days
> I'll ask Juergen.
Just curious, do you have further plan for this feature such as
accurate cursor matching? This will help if someday we want to turn
view source to edit source.
Cheers,
Bo
> Commited. If there are no problems with the new feature in the next days
> I'll ask Juergen.
This feature does not work in the trunk.
Bo
> Not in the near future but... Yes! And I think that Andre's work (TeXStream)
> may help in this direction. In principle the TeXStream (or a class derived
> from it) could store the 1:1 table of correspondence between cursor
> positions and chunks of latex. The export function could call something
On 8/13/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I've attached a patch for bug 4135, comments/documentation in the
> code (patch).
> http://bugzilla.lyx.org/show_bug.cgi?id=4135
>
> Comments? Apply?
If you are sure that the base path in the file dialog is
onlyPath(oldname) (the
> > I recently tested a WYSIWYG latex application called bakoma. It hacks
> > dvi viewer and allow edition in dvi mode, and in latex source window.
> > Using a dvi viewer/editor avoids all our layout troubles. Pretty
> > impressed.
>
> But you get WYSIWYGI rather than WYSIWYM, right?
What is that
>
> Ah yes, forgot one problem with the very last line of source code, could you
> try the attached?
Does not work either. It helps a little bit but the gray cursor either
covers the first source line, or the whole paragraph.
Bo
> Right now, if I may summarize the opinion of the lead developers: you
> will have to rebase all your work on trunk step by step, logical change
> by logical change. It's obviously a waste of time and most of the time
> invested in your branch is basically lost. I will discourage anyone
> trying t
> > That is part of the reason why I do not use branches. I simply work
> > locally, and keep my tree up to date using 'svn up'.
> Yes, though, if fixing a bug modifies a file I'm working on otherwise,
> then I can have a problem.
I have multiple trees and they usually do not rely on each other. F
> It all looks fine here, could you give a detailed explanation for a very
> short document?
>
> Btw, what's your qt version?
qt422, I am trying 4.1.
Bo
> > qt422, I am trying 4.1.
>
> qt-4.2.3 here.
Qt 4.1 does not work here. Please try 4.1 (the version lyx uses) if possible.
Bo
> What? Do we require qt=4.1, not qt>=4.1 nowadays?
Yeap.
Bo
> I very warmly recommend using "quilt" (the best place I've found for
> getting started with it is here:
> http://www.coffeebreaks.org/blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html)
When I first encountered this multiple patch/feature problem. I did a
similar search as you, and tr
> Well, if you haven't tried quilt, I suggest you do now. It's really
> nice! (I think Stefan was converted when I mentioned it to him a couple
> of months back!)
I will have a look when I get a chance.
> Regarding disk space --- if you're on a unix, you can try working with
> hard links. This re
> > I guess what makes things difficult is more a problem of attitude.
>
> Maybe you (not only you) should question your attitude as well?
This discussion has taken way too much time and emotion. Could you
two, and everyone involved, stop right here? Helping me fix bug 4108
could be a much better
> Some think that the quality of LyX is increased best by any combination
> of code reviews, the fact that more than one person understand the code,
> that changes are only done in small, incremental steps that are
> well-documented and discussed before hand, and that everyone does works
> in the s
Bug 4108 can be triggered like this:
Open a lyx file with a figure, copy the figure inset and paste. Remove
the figure, lyx crashes. (If you can not reproduce, I use float figure
inset, figure is in pdf format). The problem persists if you remove
the original or the copied figure inset.
It seems
> I can't reproduce. I tried what you suggested in the report, but still
> didn't get a crash. Can you post or send a minimal file?
OK. I have confirmed that this is our old signals + gcc 3 friend. When
I compile the program with gcc 4, the problem goes away. It should be
a missing disconnect some
> I think improving the already existing (and fairly improvable)
> spellchecker is more important than adding a new one.
The general idea is to implement a mechanism to return hints for
partial or full words. The major features in mind are
completion-on-demand (search existing text, no user config
> It was not, I committed a fix. You should review all boost::signal used
> in the code and do the same if you want to avoid further crashes.
Abdel,
Your patch does not fix the problem. It would be better if you sent
the patch to me for testing before you committed it.
There are several signals
> I think what you have in mind is not spellchecker related. Is there
> really a need for fitting spell checkers in there?
The non-GUI part of on-the-fly spellchecking means getting a
just-entered word, process it, and return a list of suggested
spelling. It is very similar to 'getting a just-ente
> > It would be better if you sent
> > the patch to me for testing before you committed it.
>
> I am pretty sure this will be needed for gcc 3 support and this is in
> line with all other signal deconnections that we have. So this must go
> in anyway.
So all signals need to be saved, and disconnec
> > So all signals need to be saved, and disconnected when an object is
> > destroyed?
>
> Basically yes.
The attached patch fixes the crash. Your patch may not be needed at
least for this bug.
Cheers,
Bo
Index: src/graphics/GraphicsLoader.cpp
> Does anybody know what the cause of "the signal problem" actually is?
I do not know your problem, but the problem with this thread is that
when an object is destroyed, its signals are still connected in qcc3,
but not in gcc4. Then, when the signal is triggered, lyx crashes with
a gcc3 build.
Th
> Why search only the existing text? A new document have very
> little of that. If you search the spellchecker wordlist for
> the language in effect, then you get more completions,
> especially for short documents.
If you read further along this thread, this is being considered and is
why I would
> > Your patch may not be needed at
> > least for this bug.
>
> It will be needed for a forthcoming bugs ;-)
> As I said, if you are serious about supporting gcc 3, you should do this
> for all boost signal connection.
I still prefer to fix the bug when I see it, rather than blindly doing
this for
Dear all,
Using a gcc3 compiled lyx, when we remove the underlying figure of a
graphic inset that is copied and pasted, lyx crashes.
This is because 'cached_item_.connect()' is not properly disconnected
when the cached_item_ is reset. This may not be related to the
signals/desctructor problem we
> I agree with Abdel. If the bug is already identified, why leave it lurking?
I have just posted a patch. The real reason for this bug does not seem
to be related to the destructor/signals problem, and I dislike the
idea of fixing a nonexistent bug that I can not test.
Cheers,
Bo
lyx1.6svn just does not work here. Maybe this is why I can not use
view-source coursor.
% /usr/local/bin/lyx16
LyX: Could not find inputfile: stdinsets.inc [around line 42 of file
[layouts/stdclass.inc]]
LyX: Error reading inputfile:
/usr/local/share/lyx16/./layouts/stdclass.inc [around line 9 of
> If I read correctly your patch, it is a problem of non disconnected
> signal so it is related. When you reset the smart pointer, you will in
> effect call the destructor.
As far as I can tell, the destructor of CacheItem is *not* called when
cache_item_.reset() is called. When I save sc_ and dis
On 8/16/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> I don't understand why you want to revert it. It will hurt
> someone sooner or later.
Because your fix might not be necessary at all. Maybe some signal
sender/receiver will be destroyed at the same time, maybe a signal
will never be sent
> Try this patch instead.
Does not work.
Bo
> The best solution actually is to store
> the signal connection inside CacheItem actually. So neither your patch
> nor mine is correct.
I have told you that the attached patch does not work (and ~Impl() is
not called). Am I missing something?
Bo
Index: src/graphics/GraphicsCacheItem.cpp
> Actually I just came to realize that statusChanged() is a signal so it
> may have multiple slots connected to it. So it is wrong to store the
> connection inside CacheItem along the signal.
Right.
> Conclusion: Both your patch and mine are correct. Sorry about the confusion.
I assume this is a
> You may want to update your tree in lib/layouts.
I have the most current svn version Maybe some encoding problem?
Bo
> Do you have the file lib/layouts/stdinsets.inc? I do, and
> it is in svn too.
I find out the reason: scons does not install the newly added stdinsets.inc.
However, lyx/trunk does not display any character on my system (See
attached). Is this a known problem?
Bo
<>
> Yes sorry, I did not find the time to disable it for X11. I'll do it
> right now, sorry for the inconvenience.
Confirmed to be fixed. Thanks.
Bo
Just let you know that after the layout files are correctly installed,
the view panel works fine.
Cheers,
Bo
> > So, shall I replace all i = i + 1 by i += 1, and commit
> > my layout2layout? Do any objections come to mind?
> >
> Perhaps we should check with Bo. I'm sure he knows exactly what version
> we require and what its capabilities are. So I'm adding him to the cc
> list here.
Lyx requires python 2
> Can I revert this patch shortly? I like my working dir to be in sync
> with the repository. Is it possible this needs to be propagated from
> trunk to 1.5 branch?
Is this in trunk or branch? If things work OK after you revert, I have
my OK. (Make sure to test middle paste within and between tabl
Dear list,
Because I get no objection to the design of the embedding feature of
lyx, I plan to add it to the trunk in the next few weeks. There is,
however, a big question on how to zip and unzip files.
There is a unzipFile function in src/support/filetools.cpp which calls
'gunzip -c'. I am not s
> > I am
> > not quite sure if this is a good idea so any comment is welcome.
>
> A library based solution is probably more robust than one based on
> external programs.
I agree. It is not easy to adapt minizip but this makes distributing
lyx a lot easier, compared to the gunzip solution.
Bo
> URL: http://www.lyx.org/trac/changeset/19666
> Log:
> Fix crash when a user removes a formula when its preview is being generated.
> (Another signal/destructor/gcc3 bug)
This is another signal/destructor/gcc3 bug: when a formula is created,
and is removed before its preview is generated, the im
This is the first of the embedding patch series. It adds functions
zipFiles and unzipToDir to src/support/filetools.[h|cpp]. This allows
the handling of zipped .lyx file.
src/support/lyxlib.[h|cpp]:
add function makedir that recursively create a directory. Function
adapted from zlib/contrib/mi
> > I agree. It is not easy to adapt minizip but this makes distributing
> > lyx a lot easier, compared to the gunzip solution.
>
> What is the problem with th zlib solution?
I am using zlib. minizip uses zlib to implement a minizip, minunz commands.
Bo
> gzip is easier than installing LyX anyway.)
> Any distro that package LyX can simply add a dependency in their
> package management system.
Then we also need tar.
> I believe zip is more common on windows, but you can't depend
> on it being present there. A unix machine doesn't necessarily have
> but gzip/gunzip doesn't do archiving, just deflates single files, doesn't
> it? IUC you need archiving also. But maybe I don't understand the problem
> well ;-)
I need file structure inside the zip file to store all embedded files.
gzip can not be used because I do not want to handle tar. Becaus
> I am also wondering if we can add zip/contrib/minizip
> (four source files) to lyx/svn to make our life a bit easier.
How about adding these four minizip files to src/support/minizip?
Bo
> That seems the logical thing to do.
Done.
Bo
Adding src/support/minizip
Adding src/support/minizip/crypt.h
Adding src/support/minizip/ioapi.c
Adding src/support/minizip/ioapi.h
Adding src/support/minizip/iowin32.c
Adding src/support/minizip/iowin32.h
Adding src/support/minizip/unzip.c
Ad
> You still don't think my systematic strategy is not worth it?
> I am 100% sure that you or any other user will see more of these in
> *released* version.
I knew what you would say about this patch. :-)
I am using lyx-1.5svn every day so I will catch such bugs and fix them
trivially. I am too la
Just to report, as far as I remember, a known problem. Moving with
arrow keys (also typing) can suddently become very slow. However, if I
select, copy and paste, lyx will speed up a lot.
Interesting.
Bo
301 - 400 of 4033 matches
Mail list logo
