gmane.editors.lyx.devel

Re: Upgrade Qt to 4.8?

John McCabe-Dansted — 2012-05-25T11:05:40

On Fri, May 25, 2012 at 5:11 PM, Jean-Marc Lasgouttes
<lasgouttes< at >lyx.org> wrote:

WorksForMe(TM).

My understanding is that If you don't use remote shares and/or you are
willing to delete stale configuration files you'll be fine. YMMV of
course.

Re: Upgrade Qt to 4.8?

Liviu Andronic — 2012-05-25T10:06:04

On Fri, May 25, 2012 at 11:11 AM, Jean-Marc Lasgouttes
<lasgouttes< at >lyx.org> wrote:
Oh, I didn't hear about that one. Sorry.

Liviu

Re: Upgrade Qt to 4.8?

Jean-Marc Lasgouttes — 2012-05-25T09:11:44

Le 25/05/2012 08:03, Liviu Andronic a écrit :

You except the bug that makes it impossible to use the File/Open dialog?

https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/946956

JMarc

Re: Upgrade Qt to 4.8?

Liviu Andronic — 2012-05-25T06:03:55

I suppose no in particular. For example Ubuntu Precise ships LyX 2.0.2
with Qt 4.8.1, and I haven't seen angry reports on our list. This
said, I have no experience with the version combination. If LyX is
critical to your productivity, I would suggest first testing this
setup in a VM.

Regards
Liviu

Upgrade Qt to 4.8?

Jerry — 2012-05-25T03:26:26

What would be the effects if any on LyX by upgrading my Qt installation from 4.7 to 4.8?

Jerry

Re: Shared Pointers

Richard Heck — 2012-05-24T19:18:06

Thanks. That's exactly what I needed.

Richard

Re: Branch 2.0.x-candidate

Richard Heck — 2012-05-24T16:58:39

You can make the danger of a bad merge, etc, less serious by:
     git co 2.0.x
     git co -b backport/7047
This creates a new branch based on 2.0.x, identifying the fix as a 
backport for #7047, say.

I don't object to the other strategy. Not everyone has to use it. But if 
some people want to
do it that way, it's fine with me.

Richard

Re: Trac improvements

Pavel Sanda — 2012-05-24T16:48:15

You have my full support :)
P

Re: Branch 2.0.x-candidate

Pavel Sanda — 2012-05-24T16:47:40

It seems to me it creates more mess than it solves and would prefer
to let the decision business in mailing list or trac rather than moving
it to git.


I usually commit to branch simulatenously with trunk commit.
Right, there is push waiting in the queue, but from my experience
Richard accepts 99% of patches, so the danger of wasted work is small.

Pavel

Re: Trac improvements

Vincent van Ravesteijn — 2012-05-24T16:41:35

Op 24-5-2012 18:34, Pavel Sanda schreef:

That's exactly why I want to change the default to lyxgit instead of lyxsvn.

Vincent

Re: Trac improvements

Pavel Sanda — 2012-05-24T16:34:18

Btw i have seen recently bugtracker using constructs r698fe32 with git,
which would be more convenient than [X/lyxgit] construct.
Haven't look whether some plugin exists for this... P

Re: Shared Pointers

Vincent van Ravesteijn — 2012-05-24T13:09:36

Op 24-5-2012 14:39, Richard Heck schreef:

doc_class = const_pointer_cast<DocumentClass>(tc->clone());

(std::tr1::const_pointer_cast or boost::const_pointer_cast, see 
support/shared_ptr.h)

Vincent

Branch 2.0.x-candidate

Vincent van Ravesteijn — 2012-05-24T12:43:03

Hi all,

Is it a good idea to create a branch "2.0.x-candidate" to where we can 
backport the fixes without asking for permission. If Richard likes all 
candidates, he just needs to fast-forward the 2.0.x branch to 
2.0.x-candidate. If not all candidates can be accepted, Richard can 
cherry-pick the commits he likes, or interactively rebase the branch 
"2.0.x-candidate" on top of 2.0.x after indicating which commits to use 
and which not.

This allows to commit to trunk and branch in one go and saves the 
questioning, waiting and answering of backport requests.

Such a branch would be a temporary one and can be rewound by Richard 
after he acknowledged all fixes.

Vincent

Re: Shared Pointers

Richard Heck — 2012-05-24T12:39:32

It's in the patch attached to "Deal with Memory Issue" I posted a couple 
days ago. Here are the relevant bits:

+typedef shared_ptr<DocumentClass>  DocumentClassPtr;
+typedef shared_ptr<DocumentClass const>  DocumentClassConstPtr;

-typedef limited_stack<pair<ParagraphList, DocumentClass const *>  >  CutStack;
+typedef limited_stack<pair<ParagraphList, DocumentClassConstPtr>  >  CutStack;

-void BufferParams::setDocumentClass(DocumentClass const * const tc)
+void BufferParams::setDocumentClass(DocumentClassConstPtr tc)
  {
  // evil, but this function is evil
-doc_class_ = const_cast<DocumentClass *>(tc);
+doc_class_ = tc->clone();
  }

+DocumentClassPtr DocumentClass::clone() const
+{
+return DocumentClassPtr(new DocumentClass(*this));
+}

The point is that doc_class_ has to be non-const, but we do want const 
stuff on the CutStack. We used to do a const_cast, but that doesn't work 
now. So we end up with an extra DocumentClass. Still, it's an 
improvement, since a lot of them will now be destroyed by the 
shared_ptr's garbage collection.

Abdel suggested passing const references to the shared_ptr around.

Richard

Trac improvements

Vincent van Ravesteijn — 2012-05-24T12:25:58

Hi all,

Some ideas to improve the trac experience:

a) It is possible to automatically update a bug report when a commit has 
been made that references a bug.

This can be done with the trac plugin:
- 
http://trac.edgewall.org/wiki/TracFaq#can-trac-automatically-update-a-ticket-when-i-commit-a-changeset

or by installing something like this as a git hook:
- 
http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-commit-hook

b) if someone can change in trac.ini the option git.shortrev_len to 8, 
we can more easily copy-paste the abbreviation to use in the bug 
reports/comments (this requires an abbreviation of 8 characters).

c) is it possible to have lyxgit the default for linking to revisions ?
- 1) rename all links in all bugreports from e.g, r20030  to 
[r20030/lyxsvn] (or something like that).
- 2) update trac.ini such that the default repository is an alias of lyxgit.

Vincent

Re: Shared Pointers

Vincent van Ravesteijn — 2012-05-24T11:35:39

Op 22-5-2012 23:37, Richard Heck schreef:

Well, either deconstify the first shared_ptr, or refrain from modifying 
the object and you can use the const shared_ptr.

Do you have some example code where you need this ?

Vincent

Re: why does import save?

John McCabe-Dansted — 2012-05-24T03:02:41

One thing is that the present importer also appears to import child
.tex files. If we lose the convert and open semantics, we must
consider: do we want to try to preserve links to the imported child
files? If so, how?

Re: annoying behavior of Lyx 2.02+ -- Language toggle

Stephan Witt — 2012-05-23T20:37:09

Currently I'm really short on time.

I'd vote for keeping the "traditional" behavior and add the optional argument "set" for internal API use.
This has to be used by the context menu code.

Stephan

Am 23.05.2012 um 20:59 schrieb Ronen Abravanel:

Re: annoying behavior of Lyx 2.02+ -- Language toggle

Ronen Abravanel — 2012-05-23T18:59:37

So, which one of the suggestions should I implement?

On Mon, May 7, 2012 at 1:39 PM, Ronen Abravanel <ronena< at >gmail.com> wrote:

Re: why does import save?

Richard Heck — 2012-05-23T12:52:45

I agree with you generally here. The conversion, like for export, should 
be done in a temporary directory, if only because the importer could, in 
principle, create all kinds of garbage in the original directory. Then 
the resulting file can be opened, we can set its filename so that it 
would, by default, be saved in the original directory and marked dirty. 
We could even ask: Do you want to save the file?

Most of these changes would be in the import() routine in GuiView.cpp.

Richard

Re: trunk regression

Richard Heck — 2012-05-23T12:43:24

Can't reproduce. I get the error dialog, click "Close", and continue.

Richard