headers
Vincent van Ravesteijn | 6 Jan 2010 03:10
Picon
Picon

VCBackend::SVN code

Pavel,

I had a look at the locking code (because of bug #6433), but I have some 
questions.

Typo ? :

void SVN::scanMaster()
{
    locker_.clear();
    vcstatus = NOLOCKING;
    if (checkLockMode()) {
        if (isLocked()) {
            locker_ = "Locked";
            vcstatus = LOCKED;
        } else {
            locker_ = "Unlocked";
-            vcstatus = LOCKED;
+           vcstatus = UNLOCKED;
        }
    }
}

 > /// The user currently keeping the lock on the VC file.
 > std::string locker_;

If the locker_ string contains the user, I would say that the variable 
should be named such that it indicates that it is a user name. But then 
I see:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jean-Marc Lasgouttes | 6 Jan 2010 09:39
Favicon

Re: LyXAction.cpp Question

rgheck <rgheck@...> writes:

> Not that it's a big deal, but it seems a bit of a waste to have both
> lyx_func_map and lyx_info_map here, since lyx_info_map actually
> contains the info that lyx_func_map does. The changes needed if we
> eliminate lyx_func_map seem pretty minor, too. Anyone know of a reason
> not to do this?

It seems that you are right about this. Unless there is some speed
argument, but I'd be surprised.

Concerning speed, why not use a vector instead of a map<FunCode,
FuncInfo>?

JMarc
Permalink | Reply | 1 comment |
headers
Jean-Marc Lasgouttes | 6 Jan 2010 09:48
Favicon

Re: Building LyX from shared libraries

Abdelrazak Younes <younes@...> writes:

> Manoj Rajagopalan wrote:
>> There is no explanation for why libtool was removed last year. Does
>> anyone know?
>>   
>
> Because it slows down compilation a lot.

And there was no evidence that we really needed it.

JMarc
Permalink | Reply | 0 comments |
headers
Jean-Marc Lasgouttes | 6 Jan 2010 09:51
Favicon

Re: :frontend::ProgressViewWidget::settingsLayout missing

"Vincent van Ravesteijn - TNW" <V.F.vanRavesteijn@...> writes:

> Would the attached be something ?

Still same error here (qt 4.2.3).

JMarc
Permalink | Reply | 10 comments |
headers
Jürgen Spitzmüller | 6 Jan 2010 10:39
Favicon

Re: #6430: Run BibTeX on every .aux-file for biblatex option "refsection=chapter"

jezZiFeR wrote:
> thank you for the hint with the workaround! I would be glad if you  
> could explain, where to put the script in the path. Would, on OSX,  
> library>texmf>tex>latex be fine? Or has it got to be in the usr- 
> folder, in temf-dist, where I also could find a bibtex-folder? Would  
> it be executable then?

You have to put it in the path where the executable programs are, where ever 
that is on the Mac (on Unix, it would be ~/bin/).

> As I use bibtex8 I would have to change the last line in the script,  
> simply like this:
> "os.popen('bibtex8 ' + f)"?

Yes. If you need options, you can add those as well, e.g.,

os.popen('bibtex8 --wolfgang ' + f)

(the --wolfgang option is always advisable with biblatex).

Jürgen
Permalink | Reply | 0 comments |
headers
Jürgen Spitzmüller | 6 Jan 2010 10:46
Favicon

Re: About the new Debug Window

Peter Kümmel wrote:
> I've committed a patch: It's still a checkbox but with three states: it
> toggles between all levels enabled, all disabled, and previous selected
> levels. Hope it's perfect now ;)

From an UI point of view, I'd very much prefer a combo or radio buttons 
instead. We do not use checkboxes this way in the LyX GUI until now, and I 
think we should keep the UI consistent.

Jürgen
Permalink | Reply | 4 comments |
headers
Jean-Marc Lasgouttes | 6 Jan 2010 10:56
Favicon

Re: About the new Debug Window

Jürgen Spitzmüller <spitz@...> writes:

> Peter Kümmel wrote:
>> I've committed a patch: It's still a checkbox but with three states: it
>> toggles between all levels enabled, all disabled, and previous selected
>> levels. Hope it's perfect now ;)
>
> From an UI point of view, I'd very much prefer a combo or radio buttons 
> instead. We do not use checkboxes this way in the LyX GUI until now, and I 
> think we should keep the UI consistent.

+1

Or we could have two normal buttons labelled 'select all' and 'deselect
all'.

JMarc
Permalink | Reply | 1 comment |
headers
Kornel Benko | 6 Jan 2010 11:42
Favicon

Re: :frontend::ProgressViewWidget::settingsLayout missing

Am Wednesday 06 January 2010 schrieb Jean-Marc Lasgouttes:
> "Vincent van Ravesteijn - TNW" <V.F.vanRavesteijn@...> writes:
> 
> > Would the attached be something ?
> 
> Still same error here (qt 4.2.3).
> 
> JMarc
> 

Same with qt 4-4.3.1 (OpenSuSE 10.3)

	Kornel
Permalink | Reply | 9 comments |
headers
Tommaso Cucinotta | 6 Jan 2010 11:43
Favicon

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

Vincent van Ravesteijn - TNW wrote:
>> I'd also want to figure out some way to allow just the
>> DispatchResult member to be modified, even when FuncRequest
>> is const. 
>>     
> You mean you want to declare it "mutable" ?
>   
I thought to this option as well, but I think it would probably be even 
worse as a hack.
Instead, what would be needed is exactly what is already in Buffer.h:

  void dispatch(FuncRequest const & func, DispatchResult & result);

So you're free to supply FuncRequest as it is now, but the problem is 
that all of the dispatch() invocations need to be reworked so as to pass 
the additional result around.

    T.
Permalink | Reply | 0 comments |
headers
Tommaso Cucinotta | 6 Jan 2010 11:58
Favicon

Re: r32678 - in lyx-devel/trunk/src: . frontends frontends/qt4

rgheck wrote:
> This particular version seems unnecessarily complex. FuncRequest 
> should just have a DispatchResult member. The pointer member is asking 
> for trouble, I think.
AFAICS, what is returned by an LFUN may be LFUN dependent. So we have 
two options:
1) use the string-encoded return mechanism, similarly to the current 
LFUN argument passing (personally disliked);
2) use a basic DispatchResult class with proper subclasses which are 
LFUN dependent. The caller of an LFUN knows what exact type to expect in 
return, so a proper DispatchResult subclass may be instantiated and 
supplied into the loop. Also, when the LFUN is intercepted, its 
implementation knows what exact type was supplied by the caller, so it 
can dynamic/static_cast<>() and properly fill the return value. This 
cannot be achieved with a simple DispatchResult member (unless you want 
to use a big union of all possible return values).

If it were for me, I would also turn the LFUN argument passing mechanism 
from the string-encoded way it is now to the 2) point described above. 
The string-encoding stuff is something related to the dispatch of LFUNs 
from the mini-shell, but that may be achieved (orthogonally) by proper 
deserialization of LFUN arguments from their string-encoded version the 
user is supposed to type.

my 2 cents.

    T.
Permalink | Reply | 4 comments |

Gmane