Re: [patch] allow to assign several extensions to a file format
On Wed, Sep 07, 2011 at 11:06:04AM -0400, Richard Heck wrote:
> >-std::string const & extension() const { return extension_; }
> >+std::string const & extension() const { return extension_list_[0]; }
> >
> >and extension_list_[0] would be an invalid address otherwise.
> >
> return extension_list_.empty() ? "" : extension_list_[0]?
That would return a dangling reference in this particular case.
So either
std::string extension() const
{
return extension_list_.empty() ? "" : extension_list_[0];
}
or the moral equivalent of
std::string const & extension() const
{
static std::string dummy;
return extension_list_.empty() ? dummy : extension_list_[0];
}
Andre'
Re: Preventing newline after a LatexType = Command line
On Wed, Jun 22, 2011 at 08:47:08AM -0400, Richard Heck wrote: > At the very end of Text::getStatus(), we have: > > if (code != NO_CODE > && (cur.empty() > || !cur.inset().insetAllowed(code) > || cur.paragraph().layout().pass_thru)) > enable = false; > > This obviously disables everything Text handles in PassThru layouts. Each time I see this I have to cry. Could this, please, please, pretty please, get a 'ough' at the end? Even if this is super cool, American, patriotic, informal, and cute, will save the world and revive the dodo, it is so terribly wrong in my little universe that I am even tempted to find out how to make patches for LyX nowadays. Andre'
Re: lyx math autocorrection
On Mon, Jun 20, 2011 at 08:21:03PM +0300, Martin Vermeer wrote: > > We'd have to look at mailing list discussions around this date to > > understand whether this was fixing a real need or just being overly > > cautious. André, do you remember about it? > > > > JMarc > > (Overly?) cautious, I think. Someone (André?) turned it off because there > were still some warts. I turned it conditionally on again because I judged > it useful in spite of this. I seem to remember real problems near math macros. Nothing concrete, though. Andre'
Re: epstopdf fails with 2.0.1svn
On Wed, Jun 15, 2011 at 12:29:00AM +0200, Enrico Forestieri wrote:
> On Tue, Jun 14, 2011 at 08:58:08PM +0200, Andre Poenitz wrote:
> > On Tue, Jun 14, 2011 at 08:16:49PM +0200, Enrico Forestieri wrote:
> > > No, I didn't find anything specific but it is clear that using the QtCore
> > > library is not advisable for this task.
> > >
> > > > PS I can do the recommit to branch, once it's in trunk.
> > >
> > > I committed the fix at r39049. However, I think that the reversion of
> > > r38746 was not necessary given that a patch had been already devised.
> >
> > I wonder whether it might be possible for you to file
> > a proper bug report for that, i.e. some minimal, but
> > complete, reproducible example that exhibits that problem
> > on bugreports.qt.nokia.com, product "Qt", component
> > "core: i/o" (or whatever is close).
>
> I don't have an account (and don't want to have one), so I cannot report
> the bug. Maybe someone with an account could do that.
I guess I could do that.
> I attach here a simple test case exhibiting the problem.
>
> Problem: When setting the environment of QProcess, a script without
> a shebang line fails to execute.
>
> How to reproduce:
> 1) Save the myprog perl script and test-env.cpp in the same directory.
> 2) Make executable myprog by "chmod 755 myprog".
> 3) Compile test-env.cpp without defining SETENV.
> 4) Launch the just compiled executable and verify that the the script is
>actually executed.
> 5) Now compile test-env.cpp by using -DSETENV.
> 6) Launch again the executable and verify that it now fails to execute.
>
> --
> Enrico
> eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' && eval 'exec perl -S
> $0 $argv:q'
> if 0;
>
> print "it works";
> exit(0);
>
> #include
> #include
> #include
>
> int main()
> {
> QProcess *proc = new QProcess();
> #ifdef SETENV
> proc->setEnvironment(QProcess::systemEnvironment());
> #endif
> proc->setProcessChannelMode(QProcess::MergedChannels);
> proc->start("./myprog");
> if (proc->waitForFinished())
> qDebug() << "Output:" << proc->readAll();
> else
> qDebug() << "Fail:" << proc->errorString();
> proc->close();
> delete proc;
> return 0;
> }
Ok, that would certainly be detailed enough for a bug report.
The path with environment ends up in execve(), the other one in
execvp(). execve() requires a shebang line or a binary, execvp()
is more forgiving. I admit that this is ... underdocumented.
The visible difference here seems to be triggered by the "missing"
"shebang line" in the script. Is that intentional?
Andre'
Re: r38997 - lyx-devel/trunk
On Thu, Jun 09, 2011 at 01:00:28AM +0200, kor...@lyx.org wrote:
> Date: Thu Jun 9 01:00:28 2011
> New Revision: 38997
> URL: http://www.lyx.org/trac/changeset/38997
>
> Log:
> Use decimal representation of QT_VERSION for moc-run in cmake build to match
> the qglobal.h computation
>
> Modified:
>lyx-devel/trunk/CMakeLists.txt
>
> Modified: lyx-devel/trunk/CMakeLists.txt
> ==
> --- lyx-devel/trunk/CMakeLists.txtWed Jun 8 22:22:27 2011(r38996)
> +++ lyx-devel/trunk/CMakeLists.txtThu Jun 9 01:00:28 2011(r38997)
> @@ -618,8 +618,7 @@
>
> # Compute qt4-version from ${QTVERSION}
> if(QTVERSION MATCHES "^([0-9]+)\\.([0-9]+)\\.([0-9]+).*")
> - MATH(EXPR QT4_VERSIONNUM
> "${CMAKE_MATCH_1}*1+${CMAKE_MATCH_2}*100+${CMAKE_MATCH_3}")
> - set(QT4_VERSION "0x${QT4_VERSIONNUM}")
> + MATH(EXPR QT4_VERSION
> "(${CMAKE_MATCH_1}<<16)|(${CMAKE_MATCH_2}<<8)|${CMAKE_MATCH_3}")
> endif()
>
> add_subdirectory(src "${TOP_BINARY_DIR}/src")
Wasn't the original problem that QPropertyAnimation was new in 4.7?
If that's the case why not #if QT_VERSION-guard the #include
and the body of the not-so-important function
IconButton::animateShow() which seems to be the only use
QPropertyAnimation? Or even remove that entirely?
Mutilating the rest of the class and fixing the Three Favourite Build
Systems does not seem to be warranted by that kind of problem, does it?
Andre'
Re: r38969 - lyx-devel/trunk/src/frontends/qt4
On Tue, Jun 07, 2011 at 03:06:30PM +0200, Enrico Forestieri wrote: > On Tue, Jun 07, 2011 at 02:43:47PM +0200, Jean-Marc Lasgouttes wrote: > > > How portable is this in your opinion? > > It assumes a bourne compatible shell, but that assumption is made > in so many places that I think it's very safe. > > The only problem that I foresee is when one of the minor numbers > in the Qt version is greater than 9. For example, it will fail > for Qt 4.10.0 (in its present form), but it can be complicated > a bit to also account for that. There won't be a Qt 4.10. Andre'
Re: Qt books
On Mon, Jun 06, 2011 at 03:18:01PM -0700, Xu Wang wrote: > Hi, I would like to learn Qt. I learn much better from physical books than > online resources, although I've heard the Qt manual is very good. > > Does anyone have suggestions for me? Your question is a bit off-topic here. Try qt-inter...@qt.nokia.com or something similar. Google's first hit for "qt books" is http://developer.qt.nokia.com/books which happens to be the "official" site. The first one (Blanchette/ Summerfield) is a very good start. > How much does Qt change from year to year? I am trying to figure out how new > the book that I look for should be. It should be Qt _4_. There's about one minor release per year, but currently Qt 5 is being discussed. This will still take a while though, and people try fairly hard to keep incompatibilities small, certainly less than the Qt 3 -> Qt 4 jump six years ago. > Is there any chance that LyX will stop using Qt in the recent future? Unlikely from my point of view, given that there are no serious alternatives for the kind of cross-platformness LyX exhibits. Andre'
Re: Lyx 2.0.0 OSX Coca version cursor problems (was OSX crashes)
On Mon, Jun 06, 2011 at 09:02:08PM +0200, Stephan Witt wrote: > Am 06.06.2011 um 17:54 schrieb Murat Yildizoglu: > > > Just to refresh this thread, I have reinstalled the standard Lyx 2 > > OSX build and the cursor problem has been corrected. So it seems > > that this problem comes from the Cocoa QT version. Has anybody else > > observed this problem with the experimental version proposed by > > Stephan? > > I'm almost sure it's Cocoa based Qt that makes the problem. Until your > report I thought it's the Qt-version what matters. See the ticket > http://www.lyx.org/trac/ticket/6920 and the discussion here > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg164633.html > > Unfortunately we have a real Scylla versus Charybdis scenario here. What was the reason to not use QFontMetrics to compute the size of a full word and interpolate the cursor inbetween (or compute the size of the "word" left of the cursor), as Jean-Marc proposed? Andre'
Re: Too much options in LyX
On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote: > On 16.05.2011 23:54, venom00 wrote: > >Vincent or someone else, can you tell me if it's OK to include a pair > >of files directly from the Qt Creator code? Just a quick reply so I > >can go on with the patch. > > Isn't QtCreator LGPL? Then it would be ok. Most of it. There are a few 3-clause BSD and a handful other files. The files have fat comments in the beginning stating under which license they are. Any of them should be compatible with LyX. Andre'
Re: LyX console warnings in LyX 2.0.0
On Sun, May 15, 2011 at 06:59:38PM +0200, Vincent van Ravesteijn wrote: > On Sun, May 15, 2011 at 6:53 PM, Uwe Stöhr wrote: > > > With LyX 2.0.0 > > - open the Tutorial > > - insert there a new table > > - set the cursor into the new table > > > > In the LyX console window I then get these messages: > > > > QWidget::repaint: Recursive repaint detected > > QPainter::begin: Paint device returned engine == 0, type: 1 > > QPainter::setPen: Painter not active > > > > What about them? > > That's a Qt problem. LyX still uses repaint() instead of update(), doesn't it? Andre'
Re: r38620 - www-user/trunk/misc/archaeology
On Sun, May 08, 2011 at 05:36:24PM +0200, Kornel wrote: > > > Lars only until 1.1.3 Lars for devel and JMarc for stable starting > > > with 1.1.4fix1 > > > > till 0.10 (~1996) announce is always from D.L. Johnson, with lines > > author:Matthias, Maintenance: DL Johnson. 0.12 (~1998) announce is > > M. Shigeru and Lars is first in credits, while Matthias has thanks > > for starting the project. so i would conclude that with 0.12 he was > > taking the care... > > Yes, that's my memory too. I think, at the time klyx was created, > Mathias was already outside. klyx was 0.10. Matthias claims Lars officially took over as maintainer "a long time" before he retired. So that would fit the picture, but it could also mean 0.8. We are clearly in a state now where real archeologists are needed ;-) Andre'
Re: Directory cleanup
On Thu, May 12, 2011 at 05:53:28AM +0200, Peter Kümmel wrote: > On 11.05.2011 20:19, Pavel Sanda wrote: > >Abdelrazak Younes wrote: > >>Side notes: > >>1: we should really get rid of boost source. > >>2: we should really get rid of boost using code > > > >whats your solution the problems with tr1::regexp in gcc discussed last time? > > We could switch to QRegEx. But it's not a 100% drop it. /me personally does not like it. Surprised? Not exactly fast, and broken interface... I am, however, definitely in favour of 1: and 2: above. Andre'
Re: Scripting vs plugins
On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote: > On 2011-05-06, venom00 wrote: > >> >> Lua > >> >>+ small and fast, > >> >>+ used in LuaTeX, so it will become more common and known in the > >> >> TeX community, > >> >>+ a Lua interpreter can be embedded in LyX with minimal > >> impact on > >> >> the binary size. > > >> > Wasn't there another thread with the result that LyX is not > >> > bloated enough? > > Actually this was a response to the "allow plug-ins" sub-thread of > the "goals for 2.1". The idea was to reduce the memory footprint by a > plugin system. But honestly, the memory footprint of LyX is really not a problem. We are talking about a 8.5 stripped binary. Some screensavers have more fat. It's really not worth even _thinking_ about a plugin system to reduce binary size. > [...] > With an embedded Lua interpreter, OTOH the impact on performance will be > small for tasks like writing/parsing config files, lyx2lyx, tex2lyx etc. > The "intelligence" can be stored in scripts that do not bloat the main > binary. What bloat, please? Andre'
Re: Development of a development model
On Thu, May 05, 2011 at 11:24:13PM +0200, Peter Kümmel wrote: > > [..] > >That's not a joke, it's not made up. I am honestly not aware > >of any single operation, not even artificial scenarios, where > >git performs worse than svn. > > Maybe this one: > > time svn co svn://svn.lyx.org/lyx/lyx-devel/trunk > real 0m27.906s > user 0m4.120s > sys 0m5.120s > > time git clone git://gitorious.org/lyx/lyx.git > real 2m41.146s > user 0m34.820s > sys 0m29.320s Ok, I have to admit that I never timed that. > OK, we have the complete history with git, but often this > isn't of interest: > > time git clone --depth 1 git://gitorious.org/lyx/lyx.git > real 0m15.568s > user 0m1.960s > sys 0m3.230s > > Is it possible to push/pull from such a clone? Not sure, I never used --depth, according to the man page it's not possible to pull/push, but it also says it's sufficient to create patches from it, so this would be even a theoretical option for people without commit rights. I doubt that's a good trade-off, though. Andre'
Re: Goals for 2.1
On Wed, May 04, 2011 at 07:45:44PM +0200, Peter Kümmel wrote: > On 04.05.2011 14:26, Abdelrazak Younes wrote: > >On 04/05/2011 00:50, Vincent van Ravesteijn wrote: > >>Hi everyone, > >>As a typical start of a new release cycle I want to poll > >>- what features are a must in the next release; > > > >Features: > >* Git based Embedded LyX. > > Couldn't we "somehow" re-use QtCreators plugins? They have > a nice plugin-system. Looks a bit inspired by OSGi. Maybe > Andre is willed and allowed to talk about it. I can certainly talk about it, and it would be hard to hide anything anyway. It's Open Source after all ;-} I think it is conceptually possible to re-use the plugin loader (just a few hundred lines of code after all), but I would not recommend it in general, and certainly not for LyX, mainly for two reason: - LyX architecture is still a bit unusual, insofar as the core drives the gui, not the other way round, so it does not fit too well into "alien" MVC setups. - I don't think there is any need to split LyX into plugins. "Reusing" the git plugin code on a conceptual level might be in possible in theory, but given that the implementation only calls the command line tool, I am fairly sure there won't be much more practical "reuse" than the lines containing the opening and closing braces of function bodies in the end ;-} Sorry to spoil the fun here. Andre'
Re: SVN mirror of git
On Wed, May 04, 2011 at 09:45:04AM -0600, Rob Oakes wrote: > With all that said, I did have a question regarding our existing > infrastructure. Whatever model we end up settling on, would it be > possible to mirror the git master branch to SVN? (Basically the same > thing we do for the git users, except in reverse.) git-svn exists, and works sufficiently well to handle "mirror" repositories. However, I personally think of it as a means to lower psychological barriers, allowing to postpone the personal mental switch or to overcome technical or political restrictions like the ones you mentioned, but not as a long-term prefered way of working. Andre'
Re: Goals for 2.1
On Wed, May 04, 2011 at 05:27:36PM +0200, Tommaso Cucinotta wrote: > Il 04/05/2011 17:16, Rob Oakes ha scritto: > > > >>Software bloat is a term used to describe the tendency of newer computer > >>programs to have a larger installation footprint, or have many unnecessary > >>features that are not used by end users, or just generally use more system > >>resources than necessary, while offering little or no benefit to its users. > [...] > >But I'm all for helping to reduce the memory footprint and optimizing code, > >but I think we should think carefully before removing existing features. > > On a related note, does anyone know how much "bloating" effect comes > from the use of more and more recent Qt (or other libraries, i..e, > boost) versions :-) ? Most certainly not. And the minimum requirements of LyX on both are not even remotely "recent". > Also, if really we have too many features, what about trying to > embed some modularity in LyX and make them dynamically loadable > on-demand ? Overengineered extra code to maintain. Plugin systemis only (or rather, "at most") make sense if there's a decent chance to have third parties creating plugins that are not maintained/distributed with the main product. For LyX, assuming a probability of zero for that case seems to be a good first approximation. > (i.e., dynamically linked libraries/plugins loaded on > demand) Or, confine some features into external tools launched on > demand, as opposed to have it integrated into the main code ? (e.g., > what is the current implementation model for the "Compare Document" > feature ? Is it "integrated" in LyX, or does it call an external > program ?) The maintenance effort will outweigh any potential benefits by several orders of magnitude. > But, first of all maybe we need clear measurements for assessing > whether or not any of the above is really necessary. I don't think it's worthwhile to spend time to come to obvious conclusions, but I certainly won't stop anyone doing that. Andre'
Re: Development of a development model
On Wed, May 04, 2011 at 04:16:13PM +0200, Vincent van Ravesteijn wrote: > On Wed, May 4, 2011 at 2:13 PM, Pavel Sanda wrote: > > > Andre Poenitz wrote: > > > Close to the current svn model, but allow people to use branches for > > > non-trivial feature sets if they like? > > > > +1 > > > > Then we can just as well stay with svn. I don't think the following are equivalent: ... > cd ~/lyx/trunk ; time svn log > /dev/null real4m28.451s user0m1.112s sys 0m0.268s ... > cd ~/lyx-git ; time git log > /dev/null real0m2.128s user0m1.264s sys 0m0.080s Yes. That's a factor of 130, and the respective outputs (if not redirected to /dev/null...) contain similar information. And it's similar for blame, diff, and any other operation that does not work on the local copy only. That's not a joke, it's not made up. I am honestly not aware of any single operation, not even artificial scenarios, where git performs worse than svn. For me the major selling point for git is not that it enables fancy workflows beyond what is possible with svn (which it obviously does) but that it can do whatever svn can do, only _much_ better. Andre'
Re: 80 chars rule (was: Too much options in LyX)
On Wed, May 04, 2011 at 12:43:05PM +0200, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > > anyone around strongly against 100-char wide rule? > > > > YES, me ! > > hmm, i should also count caps lock and exclamation marks when doing > next emoticons statistics... :) > > > "Normal Code" please, so don't come up with 20 connects beneath each other > > or the like. > > i admit that this thread is not spin off from normal code. i just dont > recognize how: > > LYXERR(level, "blabla" << x->variable << "blablabla" > << y->var << "blabla" << z->variable); > > is more readable than > > LYXERR(level, "blabla" << x->variable << "blablabla" << y->var << "blabla" << > z->variable); Ok. This shows here as: -- snip --- > i admit that this thread is not spin off from normal code. i just dont recogn ize how: > LYXERR(level, "blabla" << x->variable << "blablabla" << y->var << "blabla" << z->variable); is more readable than LYXERR(level, "blabla" << x->variable << "blablabla" << y->var << "blabla" << z->variable); -- snip --- Including the break within "recognize". Given that kind of context, would you accept that the first version is "preferable"? > that said if you agree on those few exception from 80 rule then i'll be > satisfied with such outcome of our flame. Exempting certain constructs from the rule seems to be more platable then to drop the rule completely... Andre'
Re: Development of a development model
On Wed, May 04, 2011 at 01:00:16AM +0200, Vincent van Ravesteijn wrote: > Hi all, > > I think that there is a large enough support for the new development model > and/or introduction of git to think about how to make things more concrete. > > I'm aware there might be some learning curve for developers who are not used > to git yet, so I'll not rush things. > > My plans are to first find out: First approximations and bold guesses: > - a suitable development model, Close to the current svn model, but allow people to use branches for non-trivial feature sets if they like? > - the place to store the git repo, Same place as now? Or gitorious? > - how Trac can be used with the git repo, No idea. Google finds http://trac-hacks.org/wiki/GitPlugin I haven't used it. > - how to organize the cvslog, Depends on the requirements. Might be not more then a cronjob. > - how LyX developers can get familiar to the workflow and/or the use of git. Looks like some are already familiar with it. There are tons of tutorials like http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html I think it's not even worth the effort to have a list of them in the wiki or such. Andre'
Re: Development for LyX 2.1
On Tue, May 03, 2011 at 10:10:40PM +0200, Tommaso Cucinotta wrote: > Il 03/05/2011 16:03, Richard Heck ha scritto: > >On 05/03/2011 09:25 AM, Abdelrazak Younes wrote: > >>On 03/05/2011 10:20, Edwin Leuven wrote: > >>>so let's decide to move to git (we loose nothing and gain some), > > Probably unimportant, we just lost some disk space (+30.8% space > needed for sources) > > $ git clone git://gitorious.org/lyx/lyx.git > $ du -sh lyx > 267Mlyx > > $ svn co svn://svn.lyx.org/lyx/lyx-devel/tags/lyx_2_0_0/ > $ du -sh lyx_2_0_0/ > 204Mlyx_2_0_0/ *gosh* So you really payed 63 MB for the full history of LyX sources since Sep 27, 1999, that historical moment when Lars said "New repository initialized by cvs2svn", giving you the ability to do all your history browsing, comparing, blaming, ... off-line, and bound only by the speed of your disk I/O, on a disk that's able to hold at least 460 MB of data for a build of LyX on top of 200 MB sources? Let me think... ...harder... ...really hard... Poof. Well. If I were you I'd try to get my money back. Seriously. And maybe ask someone to setup a repo without local history, to recreate the full svn experience. That would come at 123 MB in total i.e. at a cost of -81 MB for you. > [...] Also probably unimportant, is the possible lack of integration with > IDEs. The _POSSIBLE_ lack? Andre' PS: Someone who knows a good dentist who can unplug a few teeth from a table top and re-fit them into a mouth?
Re: 80 chars rule (was: Too much options in LyX)
On Tue, May 03, 2011 at 09:43:40PM +0200, venom00 wrote: > We need a limit, 100 is perfect IMSO [1]. > > venom00 (is sure someone here is still developing on terminal) Terminal or not (which I do use around 50% of the time) is not the full picture, as one can have split editors in some IDEs, too (and that's perhaps 20% of the remaining 50% for me...) Anyway, 100 is probably fine, I lost that kind of battle already in other places ;-| Andre' PS: > [1] In My Selfish Opinion, that is, given my IDE configuration. /me mumbles something gloomy about if, strncmp, getlogin, venom, 5, displaysettingspage.cpp, m_page, wrapColumn, setMaximum, and 80... *mwuahaha* [Sorry, could not resist. It just came over me ;-)]
Re: 80 chars rule (was: Too much options in LyX)
On Tue, May 03, 2011 at 08:43:07PM +0200, Pavel Sanda wrote: > José Matos wrote: > > There are several reasons associated, we should avoid to nest too much our > > code, if we have a 5 nested levels it becomes increasingly difficult to > > read > > the code. > > i didnt want to use 5 nested levels. > > > With widespread pages it is difficult to read any text, be it code or > > literature. > > > > well i dont read the code as a text. for example the second case > looks much more usefull for me, since its 2x smaller in vertical > sense and my eyes go through the code faster. > > compare these two: > connect(table, SIGNAL(rowsChanged(int)), > rowsSB, SLOT(setValue(int))); > connect(table, SIGNAL(colsChanged(int)), > columnsSB, SLOT(setValue(int))); > connect(rowsSB, SIGNAL(valueChanged(int)), > table, SLOT(setNumberRows(int))); > connect(columnsSB, SIGNAL(valueChanged(int)), > table, SLOT(setNumberColumns(int))); > connect(rowsSB, SIGNAL(valueChanged(int)), > this, SLOT(change_adaptor())); > connect(columnsSB, SIGNAL(valueChanged(int)), > this, SLOT(columnsChanged(int)) ); > connect(valignCO, SIGNAL(highlighted(QString)), > this, SLOT(change_adaptor())); > connect(halignED, SIGNAL(textChanged(QString)), > this, SLOT(change_adaptor())); > connect(decorationCO, SIGNAL(activated(int)), > this, SLOT(decorationChanged(int))); > > and > > connect(table, SIGNAL(rowsChanged(int)), rowsSB, SLOT(setValue(int))); > connect(table, SIGNAL(colsChanged(int)), columnsSB, > SLOT(setValue(int))); > connect(rowsSB, SIGNAL(valueChanged(int)), table, > SLOT(setNumberRows(int))); > connect(columnsSB, SIGNAL(valueChanged(int)), table, > SLOT(setNumberColumns(int))); > connect(rowsSB, SIGNAL(valueChanged(int)), this, > SLOT(change_adaptor())); > connect(columnsSB, SIGNAL(valueChanged(int)), this, > SLOT(columnsChanged(int)) ); > connect(valignCO, SIGNAL(highlighted(QString)), this, > SLOT(change_adaptor())); > connect(halignED, SIGNAL(textChanged(QString)), this, > SLOT(change_adaptor())); > connect(decorationCO, SIGNAL(activated(int)), this, > SLOT(decorationChanged(int))); Five out of the last seven lines wrap for me even when reading mail. That makes reading patches harder (and that's even something I still do) The last three would not if 'this, ' were omitted (that works) [...and none would be needed if it were written as connect(table, "2rowsChanged(int)", rowsSB, "1setValue(int)"); connect(table, "2colsChanged(int)", columnsSB, "1setValue(int)"); connect(rowsSB, "2valueChanged(int)", table, "1setNumberRows(int)"); connect(columnsSB, "2valueChanged(int)", table, "1setNumberColumns(int)"); connect(rowsSB, "2valueChanged(int)", this, "1change_adaptor()"); connect(columnsSB, "2valueChanged(int)", this, "1columnsChanged(int)"); connect(valignCO, "2highlighted(QString)", this, "1change_adaptor()"); connect(halignED, "2textChanged(QString)", this, "1change_adaptor()"); connect(decorationCO, "2activated(int)", this, "1decorationChanged(int)"); - but I guess I'd better not propose that ;-)] > > I don't care so much about the 80 chars limit but certainly we should set > > on > > some limit and try to follow for the reasons above. > > 100? :) Qt has 100. I personally still prefer to have two editors side-by-side on the laptop and three on the normal screen. Andre'
Re: 80 chars rule (was: Too much options in LyX)
On Tue, May 03, 2011 at 07:23:50PM +0200, Pavel Sanda wrote: > venom00 wrote: > > > The patch looks pretty good now, so I'll put it in my testing tree. > > > > I'm not completely sure of the red highlighting. Red is a color for errors, > > I'll > > try green, yellow and maybe bold. > > Moreover I want to add the "rubber" button. > > > > > Just a last nitpick: we try to keep the lines shorter than 80 > > > characters. > > btw is it still worth to keep this rule as the displays are wider and wider? > what was the rationale behind? To enable working on the code without line wrapping. And I think it still makes a lot of sense, as people are known to place several editor side by side to use the full width of their new screens... Andre'
Re: Development for LyX 2.1
On Mon, May 02, 2011 at 09:04:58AM +, Guenter Milde wrote: > Do I undestand right, that with Git it would be possible to do this > corrections/adjustments without spoiling the history -- also if no > branches are used? As long as the commits are held locally, you can reorder/merge/split them at will. Only when you "push" to the public repository, history will be set in stone (more or less...). When using branches (which you are not forced to, unless the global policy makers dictate it...) you can rearrange pretty much in all the ways you can think of. Cut bits from one branch, put into onto another, merge branches, re-order the loose ends, whatever. You can, it's really useful, but you are not _forced_ to use it. All in all it's basically a set of parallel worlds. Anything you do locally is independent of the rest of the world. When you push or pull you synchronize parts of the universes. One universe might even be called "trunk" and look like an svn repo... > Then, moving to Git would be helpfull even without > changing the rest of the workflow. Indeed. As you can pretty much mimic svn behaviour in the global repo and are locally free to use it like svn, or git without anybody else noticing, it's uniformally better then svn. Andre'
Re: Development for LyX 2.1
On Mon, May 02, 2011 at 08:46:49AM +0200, Vincent van Ravesteijn wrote: > On 2-5-2011 3:15, Andre Poenitz wrote: > > On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote: > >> [...] > >> my fear is also that while the extensive branch usage is superior from > >> the geeky point of view, its hindrance for people not so technically > >> skilled. do we want only geeks to be around? > >> [...] > > > I don't really get this. When used to it, I don't think it is > technically a very difficult workflow. Second, does that mean > that the less skilled developers are only allowed to do small > things and refrain from the larger features because they don't > know how to use the branches ? Well, the part I don't get is why suddenly using a version control system is considered rocket science. It is not. Anybody reading here will survive. > > Very good point. I don't think that's wanted, and I think it would not > > harm if any new workflow wouldn't deviate _needlessly_ from what seemed > > to have worked reasonably well for the project in the past. So even if > > there are new bells and whistles in a potential new tool there is no > > need to require their use on a "but we can!" base. > > I don't propose this based on a "because it can" base. I saw > that even a lot of small commits, were either corrected adjusted > etc. several times. Indeed. And I think we agree that the ratio of imperfect commits typically sinks when patches are allowed to "mature" locally for a day or two before being "published". With svn there's not much choice but to commit early, in order to be ready for the next hunk of work. With git one can only commit locally and fix commits later if needed, even after other local commits. Or just work exactly the same way as with svn... > How are we gonna decide which feature deserves > a branch and which doesn't ? As usual? I.e. the developer who does the work has some say in how it is done? [My personal cut-off point for 'normal patches vs branches' in git is typically around the point where applying the patches creates conflicts that are not automatically resolved] > I also don't see how this much deviates from the good old svn > workflow. In my opinion "not much, if at all", and that's also a reason why I don't understand the fuzz. Andre'
Re: Development for LyX 2.1
On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote: > [...] > my fear is also that while the extensive branch usage is superior from > the geeky point of view, its hindrance for people not so technically > skilled. do we want only geeks to be around? > [...] Very good point. I don't think that's wanted, and I think it would not harm if any new workflow wouldn't deviate _needlessly_ from what seemed to have worked reasonably well for the project in the past. So even if there are new bells and whistles in a potential new tool there is no need to require their use on a "but we can!" base. Andre'
Re: Goals and Milestones for LyX3.0
On Mon, May 02, 2011 at 12:58:53AM +0200, Pavel Sanda wrote: > Peter Kümmel wrote: > >> - Less noise in commits: a new feature in SVN sometimes comprises over 20 > >> commits in > .. > > The commits are the beats of LyX's development heart, so why kill them. > > there is actually something on this. > > its good idea that having some "final" tree where 1 feature=1 commit. > its blessing when you dig out something in history. it would spare amounts > of my time when bisecting history to find regression culprits. For bisecting I found it really useful to have not-so-fat commits. The bisecting itself is only logarithmic in the number of commits and automatable, whereas finding the actual bug in the faulty commit is linear in the size of the commit and typically manual. I don't think there's something wrong with having a big feature in a dozen commits, as long as all of the intermediate versions are working, and preferably if the version represent "logical steps". Prepering some infrastructure, maybe some refactoring, the actual feature work and finally enabling it is not an uncommon pattern. By separating the final "enabling" part from the infrastructure work which might be directly or indireactly used later use cases like "temporary removal of a feature" (testing purposes or whatever) are covered, too. So I would not be too restrictive when selecting the "True Workflow". > on the other i find the above "beats" important for life of the > community around dev list, so whatever dev model we adopt some > git-commit mailing list where things go imeddiately not waiting for > some final merged or approval feature-commit is must-have imho. That's starting to look a bit over-engineered and the need to implement an "out-of-band heartbeat notification scheme" might be a problem of the primary approach then. It's incidentally less prominent in a "1 feature = a reasonable smallish number of commits"... Andre'
Re: Some stats for 2.0 development
On Sat, Apr 30, 2011 at 02:41:55PM +0200, Pavel Sanda wrote: > hi all, > > some stats for 2.0 development. > (you will need mail client with fixed chars & proper tabs handling). > > * commit activity: > > Trunk 2.0: ... > > ... > [...] > ... 38 ... > ... *gosh* This makes the release look _really_ ancient. Andre' PS: No smiley, in order to not challenge José's claims...
Re: Too much options in LyX
Hi.
On Wed, Apr 27, 2011 at 02:07:55PM +0200, venom00 wrote:
> > +void GuiDocument::hideView() {
> > + Dialog::hideView();
> > + // Reset the search box
> > + this->docPS->resetSearch();
> > +}
Style nits: { on a separate line for the function body, and this->
seems superfluous.
> > + // Configure tree
> > list_->setRootIsDecorated(false);
> > list_->setColumnCount(1);
> > list_->header()->hide();
> > @@ -43,14 +54,28 @@
> > list_->header()->setStretchLastSection(false);
> > list_->setMinimumSize(list_->viewport()->size());
> >
> > +
> > connect(list_, SIGNAL(currentItemChanged(QTreeWidgetItem*,
Was the extra empty line intended?
> > +void PanelStack::filterChanged(QString const & search) {
> > + bool enable_all = search.length() == 0;
Perhaps clearer:
bool enable_all = search.isEmpty();
> > + // Try to cast to the most common widgets and
> > looks in it's content by each
> > + // It's bad OOP, it would be nice to have a
> > QWidget::toString() overloaded by
> > + // each widget, but this would require to change
> > Qt or subclass each widget.
I think there's no need to add comments mentioning unfeasible approaches.
A helper function or two like
bool matches(QString text)
{
text.remove('&');
return text.contains(search, Qt::CaseInsensitive);
}
might help to make that block a bit more palatable.
> > +void PanelStack::resetSearch() {
> > + this->search_->setText("");
> > +}
void PanelStack::resetSearch()
{
search_->setText(QString());
}
> > ===
> > --- src/frontends/qt4/PanelStack.h (revisione 38474)
> > +++ src/frontends/qt4/PanelStack.h (copia locale)
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> >
> > +class QLineEdit;
> > class QTreeWidget;
> > class QTreeWidgetItem;
> > class QStackedWidget;
Someone before you fumbled with the alphabetic order here ;-}
Andre'
PS: Thanks for that other mail.
Re: Development for LyX 2.1
On Thu, Apr 28, 2011 at 04:31:08PM +0200, Tommaso Cucinotta wrote: > Il 26/04/2011 20:14, Julien Rioux ha scritto: > >I don't feel the need to move to git. At all. > > I'm seeing 2 discussions merged, in this thread: > 1) what development model to use (how many branches, what & how > often to commit where, what & how often to release, etc.) > 2) what development tools to use to implement (the proposed changes to) 1). > > AFAICS vfr is actually asking for a lower number of merges into > trunk, with more testing made on alternate experimental branches, > till the features are rock stable, then merge them as a single (or a > reduced number of) commit. AFAICS, this can be done with svn as well > as with git. "Can merges be done somehow with svn"? - perhaps. "Can be done easily, as part of the normal workflow"? - definitely not. Anyway, I don't think heavy use of branches is required or needed with git. I am currently involved with two largish projects using git, one near the "branches everywhere" extreme and the other close to "the history should be linear" end, and I pretty much prefer the latter, i.e. we typically rebase small-to-medium-sized patch sets before pushing to the 'master' repository, and only merge big stuff that cannot easily be rebased or is a real merge with another public branch from the same repository. The big advantage of git for me is the ease with which "local" work is handled, i.e. what happens in the n times 8/n hours between the n dayly pushes, like work on X - see that an unrelated two-liner is needed somewhere, stash, local commit, pop stash, go on with X. This saves so much time that I have a hard time to see how anybody who has used svn and git in earnest for a few days would vote svn in this kind of discussion. Andre'
Re: A basic requested feature
On Fri, Apr 15, 2011 at 01:16:50AM +0200, Pavel Sanda wrote: > let me guess, you still develop creator under vim and gdb ;) For debugging I am really eating my own dog food. Editing is by now about 50/50 real vim/fakevim, mostly depending on whether I expect a lot of navigation, tendency falling. Funny times... Andre'
Re: #7394, Crash in reverse serach
On Fri, Apr 15, 2011 at 12:09:30AM +0200, Peter Kuemmel wrote: > > Original-Nachricht > > Datum: Thu, 14 Apr 2011 23:58:57 +0200 > > Von: Enrico Forestieri > > An: lyx-devel@lists.lyx.org > > Betreff: Re: #7394, Crash in reverse serach > > > On Thu, Apr 14, 2011 at 09:53:46PM +0200, Peter Kuemmel wrote: > > > This patch > > > > > > http://www.lyx.org/trac/attachment/ticket/7394/resetAnchor.patch > > > > > > fixes the crash in > > > > > > http://www.lyx.org/trac/ticket/7394 > > > > > > But I don't know if it introduces any side effects. > > > > This is not the correct fix, and neither is removing anchor_.clear(). > > For example, the assert is avoided but when you shift-click, the entire > > document from the beginning gets selected and not from the cursor > > position. Please, find attached the correct fix. > > > > -- > > Good, you found a fix, could you commit. > > But > anchor_ = doc_iterator_begin(buffer()); > anchor_.clear(); > > makes no sense anyway. (It was added by Andre 2008). Might be equivalent to anchor_ = DocIterator(buffer(), buffer()->inset())? Seems to have changed a few times: 8472poenitz clear(); 31795xxx push_back(CursorSlice(buffer()->inset())); 31795xxx anchor_ = doc_iterator_begin(buffer()); 22898poenitz anchor_.clear(); So at time 22898 it was not immediately obvious that someone would touch some additional code in between at time 31795, and even now it's not clear there was no code between line 3 and 4 at time 31795, after all there could have been something that was removed later... Also, 31795 seems innocent: - push_back(CursorSlice(inset)); - anchor_ = doc_iterator_begin(&inset.buffer(), &inset); + push_back(CursorSlice(buffer()->inset())); + anchor_ = doc_iterator_begin(buffer()); Andre'
Re: A basic requested feature
On Thu, Apr 14, 2011 at 05:28:05PM +0200, Pavel Sanda wrote: > Richard Heck wrote: > > On 04/14/2011 08:36 AM, venom00 wrote: > >> > >> Suggestion: use Qt Creator. I think it's the best solution. > >> > > That's what I use, though under Linux, and it is very good indeed. > > and Andre will get drunken tonight ;) p Whut diedh yu ssayh? Více pivo? Andre'
Re: compiler warnings in trunk
On Sun, Apr 10, 2011 at 10:31:47AM -0400, Richard Heck wrote:
> On 04/09/2011 06:46 PM, Julien Rioux wrote:
> >I always saw those two warnings (paraphrased):
> >Lexer.cpp:197 may be used uninitialized
void Lexer::Pimpl::verifyTable()
{
// [...]
if (table <- this line?
Doesn't look like this can ever be uninitialized. But if so,
valgrind should be able to come up with more details.
> >Server.cpp:1018 ignoring return value of write(...)
This maybe the result of someone turning on -Wunused-result
or someone adding __attribute__ ((warn_unused_result)) to
the write() declaration.
Checking the return value might actually be a good idea to make
sure all the data was actually written.
Andre'
Re: LyX 2.0 and XeTeX: Floats (figures, etc) are not translated
On Wed, Mar 23, 2011 at 09:50:25PM +0100, Georg Baum wrote:
> BTW do we have any german speaking mathematician on the list who knows
> how we should deal with the missing 'Satz' theorem (see
> http://www.lyx.org/trac/ticket/7340)?
Depends a bit on what the actual problem is.
Usually I'd associate 'Satz' with (English) 'Theorem', but (German)
'Theorem' is also sometimes used, not uncommonly for an 'important'
"Satz".
But if we just want to match the set {'proposition', 'theorem'} to the
set {'Satz', SomethingElse }, using SomethingElse = 'Theorem' and
matching translating 'Proposition' with 'Satz' does not look wrong.
I have to admit that the last time I read a math paper was a while
ago and the time span since then exceeds my typical span of attention
by a few orders of magnitude, but I don't think 'Proposition' is
heavily used in "proper" German math papers. I surely wouldn't use it.
Andre'
Re: r37945 - lyx-devel/trunk/src/frontends/qt4
On Fri, Mar 18, 2011 at 09:45:32AM +0100, Jean-Marc Lasgouttes wrote: > Le 18/03/2011 02:28, rgh...@lyx.org a écrit : > > availableLV->installEventFilter(this); > > selectedLV->installEventFilter(this); > >+selectedHasFocus_ = false; > > } > > Thanks. Note that, since this is a constructor, we are supposed to > initialize this variable (and the others that predated your change) > using the selectedHasFocus_(false) idiom. I am not sure what this > buys us, though. Nothing in case of simple types, as they won't be zero-initialized before entering the constructor body. For complex types it saves the cycles for the default-construction. Andre'
Re: Conversion Error
On Wed, Mar 16, 2011 at 08:06:10PM +0100, Kornel wrote:
> Am Mittwoch, 16. März 2011 schrieb Rob Oakes:
> > > What conversion is supposed to be happening in this case? Do you get any
> > > information on the terminal?
> >
> > Unfortunately, I haven't got a clue. I'm getting some very strange output
> > in the terminal. When I try and convert a different file, I'm getting
> > this:
> >
> > LyX: Unknown InsetLayout tag [around line 124 of file
> > /var/folders/bz/bzPXBdDMFdGOuw0oPRPjUk+++TI/-Tmp-/lyx_tmpdir.L62279/conver
> > t_layout.d62279 current token: 'charstyle' context: '']
> >
> > Followed by this:
> >
> > Error 92 returned from iconv when converting from UCS-4LE to ISO-8859-15:
> > Illegal byte sequence
> >
> > and a long stream of hex:
> >
> > Converted input: 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b 0x0073 0x0069
> > 0x0064 0x0065 0x0077 0x0061 0x0079 0x0073 0x0066 0x0069 0x0067 0x0075
> > 0x0072 0x0065 0x007d 0x000a 0x000a 0x000a 0x0048 0x0061 0x006e 0x006e
> > 0x0069 0x0062 0x0061 0x006c 0x0020 0x0064 0x0065 0x0070 0x0061 0x0072
> > 0x0074 0x0065 0x0064 0x0020 0x0068 0x0069 0x0073 0x0020 0x0068 0x006f
> > 0x006d 0x0065 0x0020 0x0062 0x0061
>
> I cannot much help, but this one is ascii, reading
> "
> \end{sidewaysfigure}
But the input seems to be two bytes per letter, so it's not UCS-4LE,
rather UTF-16 or such.
Andre'
Re: r37935 - lyx-devel/trunk/src/insets
On Tue, Mar 15, 2011 at 05:55:16PM +0100, Jürgen Spitzmüller wrote: > Vincent van Ravesteijn wrote: > > Usually the IDE has a pretty easy way of navigating to the declaration > > of a function. > > I guess our coding workflow just differs. It is well possible that mine is > blatantly amateurish. I don't use an IDE, for example. I just use a (fairly > simple) text editor and a terminal. No specific reasons for this, this is > probably just the result of how I stumbled into coding. Even non-IDEs sometimes have a way to set up macros or such. In vim e.g. (see http://vim.wikia.com/wiki/Easily_switch_between_source_and_header_file) map :e %:p:s,.h$,.X123X,:s,.cpp$,.h,:s,.X123X$,.cpp, Slightly bizarre, admittedly... Andre'
Re: r37935 - lyx-devel/trunk/src/insets
On Tue, Mar 15, 2011 at 05:28:05PM +0100, Jürgen Spitzmüller wrote: > All right, but for sure we want to have some documentation in the header > files. Having the documentation in the header is a pretty good way to make sure it does not get updated. Nobody corrects minor issues in Inset.h as this means recompilation of half of the project. Andre'
Re: r37859 - lyx-devel/trunk/src/frontends/qt4
On Sat, Mar 05, 2011 at 02:45:39PM +0100, kuem...@lyx.org wrote: > Author: kuemmel > Date: Sat Mar 5 14:45:39 2011 > New Revision: 37859 > URL: http://www.lyx.org/trac/changeset/37859 > > Log: > compile. TODO: review default parameter for replace_all > > Modified: >lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h > > Modified: lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h > == > --- lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar 5 > 12:10:35 2011(r37858) > +++ lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar 5 > 14:45:39 2011(r37859) > @@ -53,10 +53,14 @@ > ); > > /// Perform the scope-related buffer switch while searching > - void findAndReplaceScope(FindAndReplaceOptions & opt); > + bool findAndReplaceScope(FindAndReplaceOptions & opt, bool replace_all); > > /// Collect options from the GUI elements, then perform the search > - void findAndReplace(bool backwards, bool replace); > + bool findAndReplace(bool backwards, bool replace, bool replace_all = > false); > + > + bool findAndReplace(bool casesensitive, bool matchword, bool backwards, > + bool expandmacros, bool ignoreformat, bool replace, > + bool keep_case, bool replace_all); Shouldn't that be some kind of parameter stucture, instead of eight booleans? Andre'
Re: tabular*
On Fri, Feb 04, 2011 at 11:27:22AM +0100, Enrico Forestieri wrote: > On Fri, Feb 04, 2011 at 11:18:22AM +0100, Edwin Leuven wrote: > > Enrico Forestieri wrote: > > > While you are at it, wouldn't it be better renaming widthED as > > > columnWidthED, in order to avoid confusion, and tabularWidthL > > > as tabularWidthLA, in order to conform to the naming scheme? > > > > mm, there is little consistency in naming, ComboBoxes are calles CB, > > just like CheckBoxes, sometimes ComboBoxes are called CO just like > > Labels > > > > i'll have a look... > > In src/frontends/qt4/README I see: > > Widgets should be named like "fooXX", where XX is one of the following > widget types : > > CB - check box > CO - combo box > ED - line edit > GB - group box > LA - label > LC - LengthCombo > LV - QListView > ML - QTextBrowser > PB - push button > RB - radio button > SB - spin box > SL - slider > TE - text edit > TW - tree widget (FIXME: also TV in some files) I wonder whether it would not save time to just use the expanded names instead of the abbreviations. I bet by now more characters have been typed for mails discussing the topic then it would have taken to just type the names in full from the beginning ;-} Andre'
Re: Global list-getters return a copy: example theConverters()
On Thu, Jan 20, 2011 at 09:11:52AM -0500, Richard Heck wrote: > On 01/20/2011 12:34 AM, Andre Poenitz wrote: > >On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote: > >>Rich, you know the Graph code much better than me. Is it possible to have > >>real const functions to get pathes, or it is necessary to always set > >>the visited flag in vertices_. Couldn't the calculation be done in one > >>function call which then would be more expensive as consequence. > >It's not needed, it's just a consequence of the current implementation > >IIRC. The 'visited' information should not be part of the 'static' data > >of the graph, but rather a separate temporary structure that's passed > >around as separate parameter. > > > Unfortunately, we seem to use this as if it were static. This is why > there is the clear_visited boolean that gets passed into routines > like getReachable(). See e.g. Converters::importableFormats(). > Perhaps this is just some kind of optimization that could be > removed? It would be less of an issue if the importableFormats were > cached. I don't myself see why we shouldn't do that. We must decide > what formats we can import over and over and over There are two instances or so where it is called with clear_visited == true at the begin of a function and several times with ... == false later in the same function. That looks like a case for a local "visited" vector. I haven't check whether there are more complicated occurences, but if the pattern above is the only one used some refactoring seems in order. Andre'
Re: Global list-getters return a copy: example theConverters()
On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote: > Rich, you know the Graph code much better than me. Is it possible to have > real const functions to get pathes, or it is necessary to always set > the visited flag in vertices_. Couldn't the calculation be done in one > function call which then would be more expensive as consequence. It's not needed, it's just a consequence of the current implementation IIRC. The 'visited' information should not be part of the 'static' data of the graph, but rather a separate temporary structure that's passed around as separate parameter. Andre'
Re: r37245 - in lyx-devel/trunk: . config
On Tue, Jan 18, 2011 at 10:57:04AM +0100, lasgout...@lyx.org wrote: > Author: lasgouttes > Date: Tue Jan 18 10:57:03 2011 > New Revision: 37245 > URL: http://www.lyx.org/trac/changeset/37245 > > Log: > Rename --enable-profiling to --enable-gprof to pave the way for a configure > option for normal profiling > > Modified: >lyx-devel/trunk/INSTALL >lyx-devel/trunk/config/lyxinclude.m4 > > Modified: lyx-devel/trunk/INSTALL > == > --- lyx-devel/trunk/INSTALL Mon Jan 17 22:49:28 2011(r37244) > +++ lyx-devel/trunk/INSTALL Tue Jan 18 10:57:03 2011(r37245) > @@ -211,7 +211,7 @@ > > The following options allow to tweak more precisely the generated code: > > - o --enable-profiling instruments the code for use with the gprof > + o --enable-gprof instruments the code for use with the gprof > profiler. The result are only meaningful in conjunction with > --enable-build-type=release. Does gprof support still makes much sense in the times of valgrind/callgrind? Andre'
Re: Font spacing issue again
On Sat, Jan 15, 2011 at 11:35:14AM +0100, Jean-Marc Lasgouttes wrote: > Le 13 janv. 2011 à 18:44, Andre Poenitz a écrit : > >> 1) compute the metrics 8 times for a word of 8 letters 2) draw > >> letter by letter all the times. 3) or rely on more on Qt widgets > >> (i.e. use QTextEdit) instead on doing our thing. > > > > 4) Compute the metrics for a word twice, once as a whole, once by > > letter, and interpolate cursor position? > > I do not understand why we cannot only cache strings. If one needs to > place the cursor after the t of "metrics" (which is not an operation > repeated often anyway), just compute the length of "met" and place the > cursor there. > > What am I missing? Nothing I think. I just didn't think to the end. Andre'
Re: Font spacing issue again
On Thu, Jan 13, 2011 at 09:07:46AM +0100, Abdelrazak Younes wrote: > On 01/13/2011 08:48 AM, Pavel Sanda wrote: > >Stephan Witt wrote: > >>The metrics cache computes the width of every single character - > >>inclusive cacheing of it (to get better performance). But the > >>drawing is done with complete text strings and if a font supports > >>kerning e.g. it's absolutely correct to respect it on drawing. > >> > >>LyX cursor positioning simply operates in a parallel universe... > >>... and uses the metrics cache numbers. > >> > >>See ticket http://www.lyx.org/trac/ticket/6920 > >its clearly not just mac os thing. this starts to be currently > >most annoying bug we have and the proper solution probably means > >rewrite the painting routines. > > > >http://www.lyx.org/trac/ticket/7235 > > There are three solutions: > > 1) compute the metrics 8 times for a word of 8 letters > 2) draw letter by letter all the times. > 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on > doing our thing. 4) Compute the metrics for a word twice, once as a whole, once by letter, and interpolate cursor position? Andre'
Re: r36789 - in lyx-devel/trunk/src: . insets
On Thu, Dec 09, 2010 at 06:55:11PM +0100, rgh...@lyx.org wrote: > Author: rgheck > Date: Thu Dec 9 18:55:11 2010 > New Revision: 36789 > URL: http://www.lyx.org/trac/changeset/36789 > > Log: > Remove support for viewing URLs from hyperlinks. This is a security > risk, due to our lack of control over the links and the program used to > view them. Is that conceptual difference from any other external program? Andre'
Re: r36663 - lyx-devel/trunk/src
On Fri, Dec 03, 2010 at 08:58:32PM +0100, Pavel Sanda wrote: > Andre Poenitz wrote: > > Even some big guns were claiming for a while that deque is > > uniformly better > > could you be more explicit about the source? sutter? Yes, I believe so. Andre'
Re: r36663 - lyx-devel/trunk/src
On Thu, Dec 02, 2010 at 05:09:48PM -0500, Richard Heck wrote: > On 12/02/2010 04:54 PM, Vincent van Ravesteijn wrote: > >>I read somewhere that stacks are best implemented as deques. Don't ask me > >>why now, > >>but I think they are slightly cheaper. (I'm sure Andre would have a view > >>about this.) > >Some googling gives me: > > > >The C++ Standard, in section 23.1.1, offers some advice on which > >containers to prefer. It says: > > > > "vector is the type of sequence that should be used by default... > >deque is the data structure of choice when most insertions and > >deletions take place at the beginning or at the end of the sequence." > > > That's our case: It's being used as a stack, so insertions and > deletions always take place at the end. > > I guess the advantage to a deque here is that it doesn't allow you > to do things you shouldn't be doing, > like random access. A deque is more complicated (usually some kind of list of blocks of data), and it does provide random access. I don't think it's a good default choice to implement a stack, but I've seen such recommendation, too. Even some big guns were claiming for a while that deque is uniformly better then vector as "it has the same asymptotic behaviour everywhere and additionally allows insertion/deletion at the begin". This line of argumentation completely ignores the constant overhead. Andre'
Re: PATCH for ticket 7026
On Fri, Dec 03, 2010 at 07:33:58AM +0100, Stephan Witt wrote: > Am 03.12.2010 um 04:36 schrieb Enrico Forestieri: > > > On Fri, Dec 03, 2010 at 12:44:57AM +0100, Pavel Sanda wrote: > > > >> Stephan Witt wrote: > >>> There is a patch pending from Georg. > >>> I present it here again and propose to apply it. > >>> > >>> The second part of the patch is mine. > >>> It encapsulates the crucial hasDigit into an ignoreWord() method to > >>> prepare to solve the FIXME and to propose an alternate implementation. > >>> > >>> The latter is not that important... > >> > >> is Enrico fine with the isDigit part? p > > > > It's becoming a mess. We have isdigit(), isDigit(), isDigitASCII(), > > and now iswdigit() enters the scene. > > iswdigit() is POSIX standard for wchar_t arguments - our char_type > is a typedef of wchar_t. But I don't insist here. I thought it was a typedef to a 32 bit integer type, even on systems where wchar_t is only 16? Andre'
Re: r36354 - in lyx-devel/trunk/src: frontends/qt4 support
On Wed, Nov 17, 2010 at 11:00:42PM +0100, rgh...@lyx.org wrote: > Author: rgheck > Date: Wed Nov 17 23:00:42 2010 > New Revision: 36354 > URL: http://www.lyx.org/trac/changeset/36354 > > Log: > We don't generally use "static" this way in the LyX code any more. (Just > a bit of cleanup while studying other things) Still it adds a few bytes to the object file size and a few cycles to linking time. It's this kind of random, unneeded "improvements" that makes LyX development round trip times as bad as it is compared to projects with comparable source line counts. Andre'
Re: [patch] Single Instance LyX
On Wed, Nov 10, 2010 at 03:10:07PM -0500, Richard Heck wrote: > On 11/10/2010 02:17 PM, Vincent van Ravesteijn wrote: > > Op 10-11-2010 20:13, Enrico Forestieri schreef: > >>On Wed, Nov 10, 2010 at 06:14:53PM +0100, Vincent van Ravesteijn wrote: > >>>- We then depend on QtNetwork.dll/lib > >>YA dependency. This is bad for a next to useless feature. > >> > >We can maybe rewrite it to use pipes. Or we can rewrite the piped > >code to use QLocalSocket. > > > This does seem like a major dependency. If it could be removed, that > wouldn't be a bad thing. Just for the record: QtNetwork is not even half the size of QtCore (an eigth of QtGui), and I am not aware of any system or distribution that would install one but not the other. Andre'
Re: r36092 - lyx-devel/trunk/lib/lyx2lyx
On Thu, Nov 04, 2010 at 10:40:02PM +0100, rgh...@lyx.org wrote:
> Author: rgheck
> Date: Thu Nov 4 22:40:01 2010
> New Revision: 36092
> URL: http://www.lyx.org/trac/changeset/36092
>
> Log:
> Typos? Thinkos?
>
> Modified:
>lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.py
>
> Modified: lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.py
> ==
> --- lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.pyThu Nov 4 22:38:32 2010
> (r36091)
> +++ lyx-devel/trunk/lib/lyx2lyx/lyx_2_0.pyThu Nov 4 22:40:01 2010
> (r36092)
> @@ -1779,12 +1779,14 @@
> usedots = int(val)
>except:
> document.warning("Invalid \\use_mathdots value: " + val)
> +# probably usedots has not been changed, but be safe.
> +usedots = 1
>
> -if mathdots == 0:
> +if usedots == 0:
># do not load case
>return
>
> -if mathdots == 2:
> +if usedots == 2:
># force load case
>add_to_preamble(["% lyx2lyx mathdots addition",
> "\\usepackage{mathdots}"])
>return
I wonder whether such incremental improvements could be combined into
larger commits. I understand that svn is not git and so it might be not
completely trivial, but it sometimes looks a bit like fix-the-fix
commits that are not really worth to end up recorded for eternity.
Andre'
Re: r35995 - lyx-devel/trunk/src
On Tue, Nov 02, 2010 at 03:53:56PM +0100, Pavel Sanda wrote: > rgh...@lyx.org wrote: > > Author: rgheck > > Date: Tue Nov 2 15:50:07 2010 > > New Revision: 35995 > > URL: http://www.lyx.org/trac/changeset/35995 > > > > Log: > > Make sure that the members of this enum get the same value on every > > platform. > > btw on which platform will this enum starts on non zero number? It's guaranteed to be zero. Adding the ... = 0 might give more clarity, though, as in "for this enum we care about the numerical values". Andre'
Re: Inset handling question
On Fri, Oct 29, 2010 at 03:23:52AM +0200, Uwe Stöhr wrote: > Thanks, I used this for the fix: http://www.lyx.org/trac/changeset/35894 > > One last question: How do I explicitly specify that the "0" in my > patch is a pointer? 0 (and any integral constant expression that evaluates to zero such as '(4 - 2 * 2)' for that matter) is a "null pointer constant", that can be converted to (a "null pointer value" of) any pointer type. Andre'
Re: Git repos on Gitorious
On Wed, Oct 27, 2010 at 05:13:20PM +0200, Vincent van Ravesteijn wrote: > > I disagree here, we should move to gitorious altogether. Keeping an > > automatic svn update requires time (and cpu) and this time is better spent > > on development IMO. This way the periodical problems we have with the svn > > will just vanish... Having a week of transition is no big deal... > > > > Also Trac has some git plugin it seems. > > I'm not ready to move over to git. I find it hard sometimes. Sometimes > I have to spent half an hour to retrieve some commits from an endless > sea of log files because I almost lost them. > > Also, git on Windows is not very very very super. True, unfortunately. But it works. > Also, I don't feel the major advantages of git in practice. Try 'git bisect' once and you'll ignore any pain surrounding git... > It's very frustrating to recompile everything everytime you switch > between two branches (if you happen to modify the wrong headers), You can have multiple sources trees checked out, add the "other" as "remote" and merge and rebase and do whatever you'd like without touching the other repo. > if you have a feature that add or deletes files, you should run cmake > again every switch, and merging, rebasing and stuff is quite sensitive > to stupid people like me entering the wrong things. Not really. Andre'
Re: r35714 - lyx-devel/trunk/src/frontends/qt4
On Wed, Oct 27, 2010 at 06:34:22AM +0200, Vincent van Ravesteijn wrote:
> >> I did something like this for Buffer::loadLyxFile(). Where would you
> >> advice to put the UI then ? I can now spit out a lot of error messages
> >> according to the number the functions comes up with. In Buffer ? In
> >> buffer_funcs ? In GuiView ?
> >
> > Any direct user interaction in src/frontends/*,
>
> I don't want to put all the error messages in frontends/*. If you have
> another gui, you don't want to implement all the error messages all
> over again, so these need to be in src/ somewhere.
I don't comment on "Another gui" for the sake of my mental health.
Note that I did not say "error messages" but "user interaction".
Of course the/a gui can pull static/localized strings from the core
if it wishes. But the decision on how to proceed after the message
has been shown belongs into the gui.
> I think the best is to put them for e.g. in Buffer, so that it is
> easier for maintenance (close to the location where the error is
> reported).
The error _is_ reported in the Gui. Adding a new user visible string
is certainly _more_ effort this way.
> Do I need a Buffer::errorMessage(int n) function ? Or maybe
> src/ErrorMessage.cpp that stores all errormessages for the whole LyX
> project.
Reminds me of the old days, when programs produced numbers instead
of "real error messages" and the user had to look them up in the
manual ;-)
> > worker methods that can run unattended, possibly
> > bailing out on error in src/{!frontend}.
>
> That was the idea. Returning some enum-value that would tell the
> caller of the function exactly what happened. Next problem is how to
> handle the user interaction part. How can we continue where we bailed
> out to ask the user something ?
>
>
> > If errors are non-fatal they could be accumulated and returned
>
> Hmm, do we already have some accumulation design in LyX ?
>
> I wrote something for Buffer::save:
>
> enum WriteStatus {
> WriteSuccess,
> WriteFailure,
> WriteDiskFull,
> [..etc..]
> }
>
> struct WriteStatusW
> {
>WriteStatus backup;
>WriteStatus write;
> }
>
> Buffer:WriteStatusW Buffer::save()
> {
> WriteStatusW status;
>
> status.backup = makeBackup(file...);
> status.write = writeFile(file...);
>
> if (status.write != WriteSuccess) {
> if (status.backup == WriteSuccess)
>restoreBackup(file);
> }
> return status;
> }
>
> To tell the gui whether the write was succesfull or why we bailed out
> and if we have stored/restored/removed.. the backup file.
>
> > or signalled individually to the gui using a signaling mechanism that does
> > _not_
> > require the existence of an "observer" (gui or lyxserver)
>
> What does this mean in english ? Not to use the
> buffer->workareamanager->workarea->guiworkarea connection ?
Exactly.
> Using Qt signals ? Using boost ? sending an LFUN :S ?
Signals from the core to the gui. For some reason I think using _Qt_
signals would make most sense.
Andre'
Re: r35714 - lyx-devel/trunk/src/frontends/qt4
On Mon, Oct 25, 2010 at 07:43:54PM +0200, Vincent van Ravesteijn wrote:
> > The only safe way to use them is when you control not only "sender" and
> > "receiver" but also all the code paths inbetween - i.e. basically only
> > within the same function or at least not from a deeply nested function.
> > And in that cases using a singular return value does the trick as well.
> >
> > Andre'
> >
>
> I did something like this for Buffer::loadLyxFile(). Where would you
> advice to put the UI then ? I can now spit out a lot of error messages
> according to the number the functions comes up with. In Buffer ? In
> buffer_funcs ? In GuiView ?
Any direct user interaction in src/frontends/*, worker methods that can
run unattended, possibly bailing out on error in src/{!frontend}. If
errors are non-fatal they could be accumulated and returned or signalled
individually to the gui using a signaling mechanism that does _not_
require the existence of an "observer" (gui or lyxserver)
Andre'
Re: iPad?
On Mon, Oct 25, 2010 at 03:49:33PM +0200, Abdelrazak Younes wrote: > Well, most of the controller code was useless indirection and > complication (most of the controller code was necessitating almost > the same amount of code in the gui implementation). So I am ready to > bet that, at feature equality, we actually have no more code than in > the past. But of course this is difficult to measure now that we > have so much more gui features... thanks to the controller stuff > removal. For some numbers a glimpse of the old battles: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg126692.html I am surprised this was only three years ago. Andre', feeling younger suddenly.
Re: iPad?
On Mon, Oct 25, 2010 at 07:51:04AM -0400, Richard Heck wrote: > I could be wrong, but I think we now have much more application > logic in the Gui* classes then we did before the removal of all the > Controller* classes. Perhaps alot of that could just be copied over, > but it is still more work. Immediately after the removal of the controllers there was _less_ code in frontends/qt4/* then before. I think there was a mail to the list to that effect. Andre'
Re: Change Tracking and Versioning (#6058) was Re: more on collaboration
On Sun, Oct 24, 2010 at 11:01:53PM +0200, Vincent van Ravesteijn wrote: > > I took a look and this looks good so far and a bit simpler than what I > > thought would be necessary but I haven't tried to test it yet. > > > > Please test if you have time. It was a long time ago for me too that I > worked on that code. > > > I do remember that someone commented that they didn't like the use of > > > > boost::uint32_t > > > > and that (IIRC) just using an unsigned int with an assertion about its size > > should be fine. > > Yes, I read that Andre mentioned this as a personal preference. Well, > if he still feels this should be changed, he will shout again ;). > > Besides we use boost::uint32_t in more places in the code, so if > anyone changes this, please change it everywhere. Besides that, we use > more datatypes from boost: boost::int32_t, boost::crc_32_type. I think > there are people that want to get rid of boost in the end, but then > all these datatypes should be replaced. The quest to keep LyX compile times and dependencies reasonable and to reduce the level of overengineering was some major sink of time in the past and I think that any further activity in that direction (including writing this mail here...) just makes it worse. I don't have problems with using boost in the implementation _if and only if_ it provides actual benefits over less intrusive alternatives. I do have a problem with needlessly sprinkling 'boost::' over interfaces, especially if it does not add any value. Given that there seems to be an unconditional "typedef unsigned int quint32;" in qglobal.h I don't think there's any platform supported by current LyX that could not use 'unsigned int' (and an static assert in some implementation file for the unlikely case some ILP64 zombie raises its ugly head again. And if that happens, using would still be a better choice...) Anyway, I don't think I should have a say on such issues anymore. Andre'
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
On Wed, Oct 20, 2010 at 10:37:29AM +0200, Andre Poenitz wrote:
> On Wed, Oct 20, 2010 at 03:54:03AM +0200, Peter Kümmel wrote:
> >
> > > I think what's happening is this. If you export pdf (say) without there
> > > already being a pdf file there, then everything is fine. But if the pdf
> > > file exists, then LyX will try to ask the user whether to overwrite.
> > > This means creating a dialog as a child of the parent. But the parent,
> > > from what I can tell, is in the main thread, and that's not allowed.
> > >
> > > I'll paste the full error I get below. As you'll see, LyX crashes here.
> > > Here's the backtrace:
> >
> > This makes it complicated: pass a signal via Qt::QueuedConnection to
> > the gui thread and wait for the answer before continuing.
> >
> > Andre, what's the best way to wait for the answer from the gui thread,
> > QEventLoop?
>
> I personally believe that nested event loops are always evil.
> In this case I'd completely stop the export, let the gui pop up
> the dialog, and on confirmation re-initiate the export process
> with a 'force' flag or such.
I think the necessity of bidirectional core-gui communication would
be gone, if the core were driven by the gui, not the other way round:
In core (pseudo code):
Result Buffer::export(File file)
{
// No Gui code here.
if (file.exists())
return FileExistsError;
doTheExport();
return EverythingOk;
}
In gui:
void Foo::export(File file)
{
if (file.exists()) {
ConfirmOverwriteDialog dialog;
if (dialog.exec() == NotConfirmed)
return;
file.remove();
}
if (buffer.export() != EverythingOk) {
ProblemDialog dialog;
dialog.exec();
}
}
and in the server:
void Bar::export(File)
{
if (file.exists()) {
if (!forceFlagWasGiven())
return FileExistsError;
file.remove();
}
if (buffer.export() != EverythingOk)
bark();
}
Andre'
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
On Wed, Oct 20, 2010 at 03:54:03AM +0200, Peter Kümmel wrote: > > > I think what's happening is this. If you export pdf (say) without there > > already being a pdf file there, then everything is fine. But if the pdf > > file exists, then LyX will try to ask the user whether to overwrite. > > This means creating a dialog as a child of the parent. But the parent, > > from what I can tell, is in the main thread, and that's not allowed. > > > > I'll paste the full error I get below. As you'll see, LyX crashes here. > > Here's the backtrace: > > This makes it complicated: pass a signal via Qt::QueuedConnection to > the gui thread and wait for the answer before continuing. > > Andre, what's the best way to wait for the answer from the gui thread, > QEventLoop? I personally believe that nested event loops are always evil. In this case I'd completely stop the export, let the gui pop up the dialog, and on confirmation re-initiate the export process with a 'force' flag or such. Andre'
Re: r35714 - lyx-devel/trunk/src/frontends/qt4
On Tue, Oct 19, 2010 at 10:55:35AM -0400, Richard Heck wrote: > We had this discussion recently, when I introduced an exception in > math processing. There are real downsides to this of a return value. > Granted, C++ provides less support for the use of "normal" > exceptions than Java or Python does. One of the biggest downside of C++ exceptions is that they tend not to work as soon as they are thrown through intermediate layers of non-C++ code, such as e.g. event loops or other third-party code. The only safe way to use them is when you control not only "sender" and "receiver" but also all the code paths inbetween - i.e. basically only within the same function or at least not from a deeply nested function. And in that cases using a singular return value does the trick as well. Andre'
Re: split(string, delim) for TeX?
On Thu, Sep 30, 2010 at 05:06:40PM -0400, Richard Heck wrote:
>
> Does anyone have a good method for splitting a string on ":",
> specifically, in TeX/LaTeX? I've written one, but it's not pretty.
For some strange reason TeX code never looks pretty.
Something like
\def\firstbithelper#1:#2\end{#1}
\def\firstbit#1{\firstbithelper#1\end}
\edef\x{\firstbit{xx:yy}}
\message{\x}
seems to do the trick for me.
Andre'
Re: Compiling on Mac OS X using Qt/Mac Framework (libraries 4.7)
On Wed, Sep 29, 2010 at 08:09:25PM +0200, Stephan Witt wrote: > Am 29.09.2010 um 19:50 schrieb Andre Poenitz: > > > On Wed, Sep 29, 2010 at 01:24:52PM +0200, Stephan Witt wrote: > >> Am 29.09.2010 um 12:11 schrieb Jean-Marc Lasgouttes: > >>> The 'nice' way should be to have a proper .pc file (for pkg-config) in > >>> the nokia distribution. Is it here? > >> > >> I don't think so. Where would you search it? > > > > an...@millo:~ > ls /data/opt/qt/lib/pkgconfig/*.pc | wc -l > > 22 > > > We're talking about frameworks on mac... I obviously misunderstood. It seemed to me you were talking about .pc files for pkg-config. Sorry for the confusion. Andre'
Re: Compiling on Mac OS X using Qt/Mac Framework (libraries 4.7)
On Wed, Sep 29, 2010 at 01:24:52PM +0200, Stephan Witt wrote: > Am 29.09.2010 um 12:11 schrieb Jean-Marc Lasgouttes: > > The 'nice' way should be to have a proper .pc file (for pkg-config) in the > > nokia distribution. Is it here? > > I don't think so. Where would you search it? an...@millo:~ > ls /data/opt/qt/lib/pkgconfig/*.pc | wc -l 22 Not Andre'
Re: r35532 - lyx-devel/trunk/src
On Wed, Sep 29, 2010 at 02:19:24PM +0200, rgh...@lyx.org wrote: > Author: rgheck > Date: Wed Sep 29 14:19:23 2010 > New Revision: 35532 > URL: http://www.lyx.org/trac/changeset/35532 > > Log: > This doesn't need to be a vector. Should be no change of behavior. > > Modified: >lyx-devel/trunk/src/Buffer.h > > Modified: lyx-devel/trunk/src/Buffer.h > == > --- lyx-devel/trunk/src/Buffer.h Wed Sep 29 14:17:24 2010(r35531) > +++ lyx-devel/trunk/src/Buffer.h Wed Sep 29 14:19:23 2010(r35532) > @@ -71,7 +71,7 @@ > > > class Buffer; > -typedef std::vector ListOfBuffers; > +typedef std::list ListOfBuffers; But why does it have to be a list? I doubt it matters here, but std::list has per-item overhead. Andre'
Re: r35452 - lyx-devel/trunk/src/support
On Sun, Sep 19, 2010 at 11:29:09PM +0200, sa...@lyx.org wrote:
> Author: sanda
> Date: Sun Sep 19 23:29:09 2010
> New Revision: 35452
> URL: http://www.lyx.org/trac/changeset/35452
>
> Log:
> PATH_MAX is not guaranteed by POSIX (fixes bug #6906).
> Patch from Samuel Thibault.
>
> Modified:
>lyx-devel/trunk/src/support/os_unix.cpp
>
> Modified: lyx-devel/trunk/src/support/os_unix.cpp
> ==
> --- lyx-devel/trunk/src/support/os_unix.cpp Sun Sep 19 23:17:22 2010
> (r35451)
> +++ lyx-devel/trunk/src/support/os_unix.cpp Sun Sep 19 23:29:09 2010
> (r35452)
> @@ -297,9 +297,16 @@
>
> string real_path(string const & path)
> {
> +#ifdef __GLIBC__
> + char * result = realpath(path.c_str(), NULL);
> + string ret = FileName::fromFilesystemEncoding(result ? result :
> path).absFileName();
> + free(result);
> + return ret;
> +#else
> char rpath[PATH_MAX + 1];
> char * result = realpath(path.c_str(), rpath);
> return FileName::fromFilesystemEncoding(result ? rpath :
> path).absFileName();
> +#endif
> }
Is there a reason to not use the '#ifdef __GLIBC__' branch in all cases?
Andre'
Re: [patch] support for customizable horizontal lines
On Tue, Sep 14, 2010 at 04:30:58AM +0200, Uwe Stöhr wrote: > Am 13.09.2010 08:58, schrieb Abdelrazak Younes: > > >You forgot the attachement... > > Sorry. > In the meantime I found a solution - ugly but does exactly what I want. > This is my problem: > > In line 433 of TextMetrics.cpp the text width is calculated: > > int const w = max_width_ - leftMargin(max_width_, pit, ii->pos) - > right_margin; > > I need this result "w" in InsetLine::draw to be able to draw the line. The store it in the inset? Andre'
Re: r34925 - lyx-devel/trunk/src/mathed
On Mon, Jul 19, 2010 at 09:35:00PM +0200, Pavel Sanda wrote:
> Andre Poenitz wrote:
> > > Modified: lyx-devel/trunk/src/mathed/InsetMathHull.cpp
> > > ==
> > > --- lyx-devel/trunk/src/mathed/InsetMathHull.cpp Sat Jul 17 11:23:10
> > > 2010(r34924)
> > > +++ lyx-devel/trunk/src/mathed/InsetMathHull.cpp Sat Jul 17 11:53:29
> > > 2010(r34925)
> > > @@ -1755,6 +1755,7 @@
> > >
> > > int InsetMathHull::plaintext(odocstream & os, OutputParams const &) const
> > > {
> > > + // disables ASCII-art for export of equations. See #2275.
> > > if (0 && display()) {
> >
> > You don't think a 'if (0 && ...)' deserves a comment?
>
> i also wondered why you have coded it this way ;p
I don't remember, but I guess it was one of those "Make sure that snake
does not raise its head at all" vs "Works - urm - not when you need it"
issues.
Andre'
Re: r34925 - lyx-devel/trunk/src/mathed
On Sat, Jul 17, 2010 at 11:53:30AM +0200, sa...@lyx.org wrote:
> Author: sanda
> Date: Sat Jul 17 11:53:29 2010
> New Revision: 34925
> URL: http://www.lyx.org/trac/changeset/34925
>
> Log:
> comment
>
> Modified:
>lyx-devel/trunk/src/mathed/InsetMathHull.cpp
>
> Modified: lyx-devel/trunk/src/mathed/InsetMathHull.cpp
> ==
> --- lyx-devel/trunk/src/mathed/InsetMathHull.cpp Sat Jul 17 11:23:10
> 2010(r34924)
> +++ lyx-devel/trunk/src/mathed/InsetMathHull.cpp Sat Jul 17 11:53:29
> 2010(r34925)
> @@ -1755,6 +1755,7 @@
>
> int InsetMathHull::plaintext(odocstream & os, OutputParams const &) const
> {
> + // disables ASCII-art for export of equations. See #2275.
> if (0 && display()) {
You don't think a 'if (0 && ...)' deserves a comment?
Andre'
Re: Using Qt Constructs in Core
On Tue, Jun 29, 2010 at 10:42:36AM -0400, Richard Heck wrote:
>
> >Thanks for the pointers. Sorry for not providing more context about
> >what I am trying to accomplish. The addition of a vector into the
> >TocItem class was to give me a place to store other insets that might
> >also be present in the paragraph.
> >
> ><< I think he really does mean: vector *>>
> >
> >That's correct. I've rewritten the InsetText class to identify Note
> >insets and add them to this vector. It then gets unpacked to a second
> >column of the Table of Contents model and used in various custom views
> >(such as the expanded outline pane).
> >
> >I know that it looks strange, but there really is some method to the
> >madness. I'm not sure if it is the best method for storing and
> >retrieving this type of information, but it seems to be working pretty
> >well so far. I should probably send along a patch that shows all of
> >these changes in context to get feedback ...
> >
> I'm still a bit puzzled, though maybe seeing the whole code would
> clear things up. [...]
Maybe we should try to shed some light on the issue.
In
struct Foo
{
std::vector f;
};
the type 'Foo' is "incomplete" until the definition is finished, i.e.
basically up to the location of the '}'.
std::vector requires T to fulfill the "assignable" concept. I haven't
found chapter and verse but I'd bet an incomplete type is not "assignable".
Now, 17.4.3.6.2 explicitly gives the compiler implementors a choice what to
do in such situations. gcc chooses (as any other compiler I am aware of)
to do the sensible thing, namely to simply to compile the code without
further ado.
However, gcc also provides the user with a choice to select insane
behaviour, i.e. to bail out whenever the concept is not met, even if
the code could be compiled and would work fine.
That's the behaviour LyX selects unless it is configured with
--disable-concept-check .
The fact that replacing std::vector with QVector works even in the
presence of enabled concept checks is that QVector does not enforce
the concept by artificially breaking the compilation.
Using std::vector works because 'Foo *' is a complete type even
if Foo itself is incomplete.
Why using std::vector * works is currently unclear to me as Foo
is as incomplete as in the direct case. Maybe we've not seen yet the
culmination of concept check frenzy and this will break later. For
now it looks like the solution with the lowest impact, though.
Andre'
Re: Using Qt Constructs in Core
On Tue, Jun 29, 2010 at 09:11:26AM -0400, Richard Heck wrote:
> On 06/29/2010 08:05 AM, Abdelrazak Younes wrote:
> >On 06/29/2010 01:46 PM, Pavel Sanda wrote:
> >>Andre Poenitz wrote:
> >>>One could argue that it allows the kind of code that's conceptionally
> >>>closest to the model Rob has in mind to compile out-of-the-box, but
> >>does qvector provide something special compared to std::vector?
> >
> >QVector doesn't require a default constructor.
> >
> >Two solution here to stay with vector:
> >1) give TocItem a default constructor
> >
> It has one:
> class TocItem
> {
> friend class Toc;
> friend class TocBackend;
>
> public:
> /// Default constructor for STL containers.
> TocItem() : dit_(0) {}
>
> >2) use vector instead.
> >
> I think he really does mean:
> vector *
> But I'm not absolutely sure about that.
Both would work, but the <...*> is uglier to handle.
Andre'
Re: Using Qt Constructs in Core
On Mon, Jun 28, 2010 at 05:42:11PM -0400, Richard Heck wrote: > On 06/28/2010 03:30 PM, Andre Poenitz wrote: > >On Mon, Jun 28, 2010 at 12:47:50PM -0400, Richard Heck wrote: > >> > >>I think it remains LyX policy not to use Qt in the core. This is not > >>necessarily something that everyone agrees with, but it is still the > >>policy. > >This has been voted upon on the Developer Meeting in Berlin on Nov 14, > >2008 (plus minus one day) and the outcome _I_ remember was "it's ok to use > >if there's a good reason for it". > > > >I probably should have set some precendence afterwards by changing some > >random pieces so this does not get "accidentally" forgotten. > > > If that was the decision, then I certainly do not mean to stand in > the way of it. I wasn't at that meeting and mostly just tried to > keep up with who was drinking how much. ;-) Anyway, if there is good > reason, then I wouldn't object. But I'm not sure there is good > reason here. That's a different point indeed. One could argue that it allows the kind of code that's conceptionally closest to the model Rob has in mind to compile out-of-the-box, but the extra indirection needed with std::vector does not really hurt much in this particular case either. And, of course, one could simply disable concept checks. Might even save a tree or two.. Andre'
Re: Using Qt Constructs in Core
On Mon, Jun 28, 2010 at 12:47:50PM -0400, Richard Heck wrote: > On 06/28/2010 12:28 PM, Rob Oakes wrote: > >Dear LyX-Developers, > > > >I have spent most of the morning trying to resolve a compiler warning > >involving std::vector. After soliciting advice from a couple of > >different people, it seemed that the easiest solution would be to use > >QVector instead of the standard library implementation. > > > >However, when I tried to include QVector into TocBackend.h, the compiler > >simply wasn't able to find it. I tried reconfiguring and even deleting > >the build directory to start over. Neither attempt worked. > > > >Is there something that I'm missing? Is there a file that I need to > >include in order to use Qt Constructs in the core? > > I think it remains LyX policy not to use Qt in the core. This is not > necessarily something that everyone agrees with, but it is still the > policy. This has been voted upon on the Developer Meeting in Berlin on Nov 14, 2008 (plus minus one day) and the outcome _I_ remember was "it's ok to use if there's a good reason for it". I probably should have set some precendence afterwards by changing some random pieces so this does not get "accidentally" forgotten. Here we are, not even two years later, same old discussion... Andre' PS: At least as indication that it was on the agenda: http://wiki.lyx.org/Devel/LyXMeeting2008. It was the first topic discussed. I later tried to act on the std::tr1 one, but failed as Peter(?) digged out a compiler that did not compile it. > What was the compiler warning, etc? I think the compiler refused to compile formally illegal but practically harmless code.
Re: Some questions relating to Cursor & MathAtom
On Mon, Jun 14, 2010 at 09:12:51AM +0200, Vincent van Ravesteijn wrote:
> > * Conceptually what is an anchor in a Cursor?
>
> The anchor is the starting point of a selection. If you have selected
> the word "hello" starting from the 'h' to the 'o', the anchor is
> positioned at 'h' and the cursor at 'o'.
>
> > * What does it mean for an inset to be "locked" ?
>
> I've no idea, but according to the comment: "/// returns whether
> changing mode during latex export is forbidden".
I think originally it was use to make complex insets behave like single
characters for cursor movement. I.e. you could 'lock' a, say, fraction
containing \frac{\partial}{\partial x} and it would act as a single unit
afterwards, i.e. the cursor would move from before the inset to behind
the inset with a single 'CursorRight' stroke, and not enter the
numerator of the fraction.
Having said that, I have no idea how 'locked' is used nowadays.
> [...]
> > * What exactly is a MathAtom. Not sure I understand how InsetMath and
> > MathAtom work together... if you could give a short
> > conceptual description that would be very useful
>
> I don't think I can explain you any better than the comment in MathAtom.h:
>
> "Wrapper for InsetMath * with copy-semantics
>
> The MathAtom owns the InsetMath * and is responsible for proper cloning and
> destruction. Every InsetMath * should be put into a MathAtom after its
> creation as soon as possible."
>
> As you can see in the code, the MathAtom class doesn't do an awful
> lot. It only clones the InsetMath* inset whenever the MathAtom is
> copied. I guess it is just a mere wrapper .. :S
Hard to believe anyone reads documentation ;-)
Andre'
Re: XML format status
On Tue, Jun 08, 2010 at 04:29:21PM +0200, Abdelrazak Younes wrote: > On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote: > >>What is the current status or thinking of the XML format for lyx 2? > >> > >Ideally, LyX 2 would have an XML file format. However, no-one is > >actively working on the issue, so we postponed it. > > > >As far as I know, we didn't really decide when and how to do the transition. > > I worked recently with JSon format (www.json.org), cleaner to the > human, faster to parse and less verbose than XML, quite nice... This might indeed be a good option. Andre'
Re: Helping out
On Mon, Jun 07, 2010 at 10:29:56PM +0200, Peter Kümmel wrote: > Am Montag, den 07.06.2010, 21:42 +0200 schrieb Peter Kümmel: > > Am Montag, den 07.06.2010, 12:37 -0600 schrieb Rob Oakes: > > > I've been using QPlainTextEdit as a test widget for the > > > outliner/corkboard extensions, and I've been very happy with its > > > performance. Even when running in my laptop within a virtual machine, > > > performance is near instantaneous. > > > > I've tested it, it's still too slow, even the messages in qtcreator > > are faster. Maybe there are other reasons which slow down lyx so much. > > Found the reason: the debug messages were not buffered. Now it waits > 200ms until the progress widget is updated. So opening the User's Guide > is now possible with all messages enabled. Would a queued connection between whateven produced the debug messages and whatever puts them in the view help? Andre'
Re: Helping out
On Fri, Jun 04, 2010 at 07:58:13AM +0200, Peter Kümmel wrote: > Am Sonntag, den 30.05.2010, 19:56 +0300 schrieb Amir Rachum: > > Hi guys, > > I just downloaded the LyX code base and I would like to help you > > people with one of the most useful pieces software I ever had. > > However, I am not sure how I can help seeing as the code base is > > really big and confusing and I was wondering if there's some external > > documentation for the code, > > and whether there's some "low hanging fruits" bugs/enhancements that I > > can handle at this point. > > Any pointers? > > Here's an idea: The "Debug/Progress Messages" widget is very slow: > enable all debug messages an load the User's Guide and you will see. > > The reason is the QTextEdit which is used for displaying the messages > (outTE defined in ProgressViewUi.ui). Using a QTreeView and as model a > QStandardModel should be much faster, at least it is worth a try. QPlainTextEdit might be an option, too. Andre'
Re: r34590 - lyx-devel/trunk/src/frontends/qt4
On Fri, Jun 04, 2010 at 03:24:04PM +0200, v...@lyx.org wrote: > Author: vfr > Date: Fri Jun 4 15:24:03 2010 > New Revision: 34590 > URL: http://www.lyx.org/trac/changeset/34590 > > Log: > Fix bug #6606: Crash when reverting a document with a not available document > class. > > If the document class is not available, we now issue a warning for the user. > This triggers a focusInEvent of the WorkArea and the cursor is issued to > start blinking. However, when reverting a document the cursor is probably > invalid and there has been no chance yet to fix it as we are still reading > the file. > > The solution is to not show the cursor when the view is still busy. > > Modified: >lyx-devel/trunk/src/frontends/qt4/GuiView.cpp >lyx-devel/trunk/src/frontends/qt4/GuiView.h >lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.cpp > > Modified: lyx-devel/trunk/src/frontends/qt4/GuiView.cpp > == > --- lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Thu Jun 3 23:24:20 > 2010(r34589) > +++ lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Fri Jun 4 15:24:03 > 2010(r34590) > @@ -1011,8 +1011,15 @@ > } > > > +bool GuiView::busy() const? Andre'
Re: Branch frozen
On Tue, May 18, 2010 at 05:52:54PM +0200, Stephan Witt wrote: > Am 17.05.2010 um 21:27 schrieb Andre Poenitz: > > > On Mon, May 17, 2010 at 07:20:34PM +0200, Pavel Sanda wrote: > >> Jürgen Spitzmüller wrote: > >>> Since I go no more translation updates after the mailing list > >>> revival, I will try to set up Lyx 1.6.6 now. Please stand by. > >> > >> please make it clear in the announce that we encourage people to build > >> it against Qt 4.5 and not 4.6 (#6608). > > > > Can anyone remind me what the issues with Qt 4.5/4.6/4.7 are? > > Andre', do you think LyX builds with Qt 4.7 are running better then with 4.6? That's what I'd try to figure out once I know what the problems in 4.5 and 4.6 are. The problems being present only on Mac does not make it easier for me, though... > Should I try this? > And what's the release plan for 4.7? Even if I knew a date the answer would be "Releases are announced when they are out" ;-) I am sort of waiting for it myself. In any case I would not expect much changes (if any at all) in the areas that are interesting for LyX before 4.7.0 from now on, so for all practical reasons 4.7.0 beta1 should be as good or as bad as the final from LyX's point of view. There have been changes to the font handling in 4.7 cycle, also regarding the x positioning of glyphs. I've been bitten by one bug there myself, but this has been fixed again in the mean time. Maybe someone who knows how to reproduce the 4.5/4.6 problem could indeed try 4.7.0 beta and see whether it makes a difference? Andre'
Re: Branch frozen
On Mon, May 17, 2010 at 07:20:34PM +0200, Pavel Sanda wrote: > Jürgen Spitzmüller wrote: > > Since I go no more translation updates after the mailing list > > revival, I will try to set up Lyx 1.6.6 now. Please stand by. > > please make it clear in the announce that we encourage people to build > it against Qt 4.5 and not 4.6 (#6608). Can anyone remind me what the issues with Qt 4.5/4.6/4.7 are? Andre'
Re: r33864 - in lyx-devel/trunk: lib/doc src
On Thu, Mar 25, 2010 at 01:30:59PM +0100, Enrico Forestieri wrote:
> On Thu, Mar 25, 2010 at 01:44:16AM +0100, rgh...@lyx.org wrote:
> > + bformat(_("The document class requested\n"
> > +"\t%1$s\n"
> > +"requires external files that
> > are not available.\n"
> > +"The document class can still
> > be used, but LyX\n"
> > +"will not be able to produce
> > output until the\n"
> > +"following prerequisites are
> > installed:\n"
> > +"\t%2$s\n"
> > +"See section 3.1.2.2 of the
> > User's Guide"
> > +"for more information."),
>
> I think that hardcoding the section number is not right. You cannot be
> sure that it doesn't change in future and that it is the same in all
> translated manuals.
This is certainly true, but setting up a mechanism to automatically
extract the number is plain overkill.
There's btw nothing stopping a translater from translating above
message to "[...]Siehe Abschnitt 4.5.1.3 im Nutzerhandbuch [...]"
Andre'
Re: Compiling with Qt 4.2
On Wed, Mar 24, 2010 at 11:31:56PM +0100, Enrico Forestieri wrote: > On Wed, Mar 24, 2010 at 10:47:24AM +0100, Jean-Marc Lasgouttes wrote: > > Le 24/03/2010 00:45, Enrico Forestieri a écrit : > >> Qt 4.3 and 4.4 series were unusable on non-windows and non-linux systems. > > > > I thought 4.5 and 4.6 were not usable for Mac OS. > > That's surprising, as Mac OS is one of the supported platforms. Tier 1 even. Andre'
Re: [Prototype] Dialog to produce backtrace after each crash; on Windows should I use GDB, vsjitdebugger.exe, or ... ?
On Wed, Mar 10, 2010 at 02:29:47AM +0800, John McCabe-Dansted wrote: > I suspect many Windows people would prefer not to have to install GDB. > Apparently it is possible to use e.g. the MSVC debugger on the command > line and "attach it to the process by running vsjitdebugger.exe -p > ProcessId from the Windows command line". In this case you don't have a choice of debuggers once you choose a compiler. Andre'
Re: [Prototype] Dialog to produce backtrace after each crash; on Windows should I use GDB, vsjitdebugger.exe, or ... ?
On Wed, Mar 10, 2010 at 02:29:47AM +0800, John McCabe-Dansted wrote:
> + // We could use a callback instead of using QtGui here
> + // doAssert_callback(str);
> +
> + QMessageBox::critical( (QWidget*)0,
> + QString(to_utf8(_("Assertion Triggered")).c_str()),
QString(const char *) uses ("usually") Latin1. Also the (QWidget *)
cast is both ugly and unneeded ;-)
Andre'
Re: Greek text mixed with English
On Tue, Mar 02, 2010 at 02:35:09PM +0100, Jürgen Spitzmüller wrote: > Guenter Milde wrote: > > Then we disagree on the weighting of practicability vs. purity. > > I think we disagree on the weighting of correctness. I think we should not > integrate functionality in LyX that allows the user to produce incorrect > output. And a Vietnamese word that is hyphenated with English rules _is_ > incorrect by all means. The example is a single word in Vietnamese. This can be easily used in a way that hyphenation will not be needed at all. Reconfiguring the whole setup is also in my eyes complete overkill. Andre'
Re: #5238: LyX 1.6 fails with non-ascii chars in path (on Windows)
On Mon, Feb 22, 2010 at 08:07:56PM +0100, Vincent van Ravesteijn - TNW wrote: > Depends.exe says: > > "class QString QString::fromWCharArray(unsigned short const *,int)" > > So, qt defines/typedefs wchar_t as unsigned short ?? No, that's not Qt, but Windows, in msvcrt.h if memory serves right. > A simple google search says > > " Pretty much every important string function has both a > narrow and a wide string version, and every one would have to be > wrapped in a #if USE_WCHAR_T block otherwise." > > But Qt has only a short one defined ? No, Qt uses the wchar_t of the platform for the to/fromWChar functions to communicate with wchar_t based functions of the host system. On Windows that's a 16 bit type, on *nix traditionally 32 bit. QString is internally UTF-16 on all platforms. Andre'
Re: #5238: LyX 1.6 fails with non-ascii chars in path (on Windows)
On Mon, Feb 22, 2010 at 01:50:09PM +0100, Vincent van Ravesteijn - TNW wrote:
>
> >> No.
> >> The above error message states that
> >> QString::fromWCharArray(wchar_t const *,int) is the problem.
> >> I don't understand the error message but it seems that fromWCharArray
>
> >> needs to be linked via a header file.
> >
> >That header file is , which is already included. There, you
> can
> >find the declaration:
> >
> >class Q_CORE_EXPORT QString
> >{
> >...
> >static QString fromWCharArray(const wchar_t *, int size = -1);
> >...
> >}
> >
> >so, I really don't understand why you get the error. Are you sure you
> are
> >linking the QtCore library?
> >
>
> I see the same, and I don't know what the problem is either. The QString
> header can be found, Qstring can be used, just not this static function.
> Maybe it is not exported or something..
The function is new in 4.2, so one possibility is that you compile
against 4.2 headers but link against 4.1 libraries.
Export might be an issue, too. Checking the library with 'depends.exe'
might give a clue.
Andre'
Re: [Patch] Rats and Unsafe use of fixed width arrays.
On Thu, Feb 18, 2010 at 12:12:59AM +0800, John McCabe-Dansted wrote: > [..] > If those two things look OK, is the attached patch ready to commit? Looks ok to me. Andre'
Re: Can't build lyx 1.6.5 on OpenSolaris using Sun Studio 12u1
On Sun, Feb 14, 2010 at 10:09:58AM +0100, Frank Thieme wrote: > >> 2. src/support/debug.h: DEBUG is defined as DEBUG = (1 << 31) > >> what is out of range for enum (32 bit) and I guess should be DEBUG > >> = (1 << 30) as there is no 30, yet. > > > > 1 << 31 is within the 32 bit range. > > mmh, yeah, you are right. Why does the compiler complain then? > > Error: lyx::Debug::Type is not within the range of a long or unsigned long. Just for the record: after a hint from Kornel and Frank's testing we established that 1u << 31 does the trick and is supposed to work according to the Standard. 1 << 31 is legal, though, but the outcome depends on the internal representation of signed integers. I doubt, however, that Sun uses something else than two's complement, so the compiler error message is somewhat ... "unusual". Andre'
Re: Can't build lyx 1.6.5 on OpenSolaris using Sun Studio 12u1
On Sat, Feb 13, 2010 at 11:21:01PM +0100, Frank Thieme wrote:
> Hi!
>
> I found the problem - I have to use "-library=stlport4" because of the
> use of boost. But now there are some more problems:
>
> 1. Trailing commas in enums - this is part of C99, but not of C++ standard
Right.
> 2. src/support/debug.h: DEBUG is defined as DEBUG = (1 << 31)
> what is out of range for enum (32 bit) and I guess should be DEBUG
> = (1 << 30) as there is no 30, yet.
1 << 31 is within the 32 bit range.
I don't think LyX is supported on machines with ints with less than
32 bit so I don't see the problem here.
> 3. a forgotten static_cast in src/support/FileName.cpp
@@ -558,7 +558,7 @@
crc.process_block(beg, end);
result = crc.checksum();
- munmap(mm, info.st_size);
+ munmap(static_cast(mm), info.st_size);
close(fd);
This seems to be Solaris-specific. So a configure check might be needed
(unless we decide an #ifdef is fine...)
docstring indent;
if (ind < 0) {
- indent.insert(0, -ind, ' ');
+ indent.insert(static_cast(0), -ind, ' ');
This looks strange. Why is that needed? Is the compiler confused by overloads?
If so, '0u' might look a bit better than 'static_cast(0)'
Andre'
Re: [Patch] Rats and Unsafe use of fixed width arrays.
On Sat, Feb 13, 2010 at 01:53:40PM +0800, John McCabe-Dansted wrote:
> I thought I'd run the LyX code base through the RATS static analysis
> tool. All it did was report every single occurrence of a fixed width
> array in LyX. Never-the-less, in some cases the use of the fixed array
> seemed dangerous or incorrect.
> [...]
>
> 3) I guess that app does not access argv[0],
Maybe our code does not trigger it, but it's not guaranteed.
> but to make it clear we could initialize it anyway.
> int argc = 1;
> char * argv[1];
> + argv[0] = (char *)"\0";
> +
I'd even use
char * argv = { "", 0 };
or maybe even
char * argv = { "lyx", 0 };
to make sure it's NULL-terminated.
> char * argv[1] = { 0
> + argv[0] = (char *)"\0";
[This would make argv[0] equal to two NUL characters. Not that it hurts,
but it's a bit misleading...]
Andre'
Re: r33422 - lyx-devel/trunk/src/frontends/qt4
On Thu, Feb 11, 2010 at 03:21:34PM +0100, Jürgen Spitzmüller wrote: > Abdelrazak Younes wrote: > > So we are only allowed to compare it with OpenOffice or MS Word then? > > Nobody allows or disallows anything. I just think we should keep in mind what > LyX aims to be. > > > OK... both programs provides less and less dialogs because of the > > extensive use of context menus. > > I cannot believe that. Almost every HIG states that context menus are only an > addition to existing UI. i personally think it's stupid to have 1000 obscure options in the main menus if 980 of them make sense only in a given context. Andre'
Re: r33408 - in lyx-devel/branches/BRANCH_1_6_X: . src/frontends/qt4
On Wed, Feb 10, 2010 at 12:42:52PM +0100, sp...@lyx.org wrote:
> Author: spitz
> Date: Wed Feb 10 12:42:52 2010
> New Revision: 33408
> URL: http://www.lyx.org/trac/changeset/33408
>
> Log:
> * GuiErrorList.cpp:
> - use GUIfied strings (bug 6397).
>
> Modified:
>lyx-devel/branches/BRANCH_1_6_X/src/frontends/qt4/GuiErrorList.cpp
>lyx-devel/branches/BRANCH_1_6_X/status.16x
>
> Modified: lyx-devel/branches/BRANCH_1_6_X/src/frontends/qt4/GuiErrorList.cpp
> ==
> --- lyx-devel/branches/BRANCH_1_6_X/src/frontends/qt4/GuiErrorList.cpp
> Wed Feb 10 11:24:10 2010(r33407)
> +++ lyx-devel/branches/BRANCH_1_6_X/src/frontends/qt4/GuiErrorList.cpp
> Wed Feb 10 12:42:52 2010(r33408)
> @@ -31,6 +31,23 @@
> using namespace std;
> using namespace lyx::support;
>
> +namespace {
> +
> +string const guiErrorType(string const s)
> +{
> + if (s == "docbook")
> + return N_("DocBook");
> + else if (s == "literate")
> + return N_("Literate");
> + else if (s == "platex")
> + return N_("pLaTeX");
> + else if (s == "latex")
> + return N_("LaTeX");
> + return s;
> +}
Why a copy and not a string const & ?
[Also, I personally prefer no 'else' after a 'return'. But we don't have
a rule about that]
string const guiErrorType(string const &s)
{
if (s == "docbook")
return N_("DocBook");
if (s == "literate")
return N_("Literate");
if (s == "platex")
return N_("pLaTeX");
if (s == "latex")
return N_("LaTeX");
return s;
} // namespace anon
Andre'
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
On Wed, Feb 03, 2010 at 12:40:04PM +0100, Peter Kümmel wrote: > I would also introduce shared libraries which help to avoild > circular dependencies between the libraries, especially when building > Dlls on Windows, but maybe there is also a GCC flag to forbid such > dependencies . Linking with --no-undefined --allow-shlib-undefined might do the trick. Andre'
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
On Wed, Feb 03, 2010 at 06:27:06PM +0100, Peter Kümmel wrote: > Peter Kümmel wrote: > > Peter Kümmel wrote: > >> Originally it was the Model-View-Controller pattern, so isn't a > >> controller the perfect candidate for the central dispatcher? > >> > > > > Wouldn't it be best to completely unlink the model and view like in > > attached image, found as figue 4-6 in > > http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html > > Diving a little bit deeper into the Apple's docs I must admit: > Documentation at it's best! > Such docu I miss for Qt, most there is a extended doxygen API > description only, no big-picture is given any where. > > By the way, being again off-topic-on-the wrong-list: > Are there plans to create a "Qt Interface Builder" > which exports .qib files? What's a .qib file? I only find http://filext.com/file-extension/QIP which seems unrelated. Andre'
Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4
On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote: > Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz: > > > How do we proceed now ? > > > > I think it's time to use signal/slots, this time in the right direction. > > The buffer emits a message, possibly with an indication that it is > > temporarily and the view (or the server...) connects to it. > > > > Andre' > > Does this also mean currently we have no clear Model/View design? Sort of. Right now the Gui is basically signaling the Core to change and the Core pushes changes to the Gui. Which is pretty wrong. Andre'
