Re: Virtual meetings

[Abdelrazak Younes]

On Sun, Jan 3, 2021 at 9:39 PM Pavel Sanda  wrote:

> I would suggest we meet Mon 11 Jan, 5pm CET (4pm UTC, 11am EST) unless
> there is a better proposal.
>
> I could send zoom invitiation if you all are ok with that. Otherwise
> suggest
> your tool and manage the managment side of the meeting.
>

Hey guys,

Long time no see! I will try to join if I am invited, just for the sake of
seeing your faces :-)

Abdel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Installer: Future Issues

[Abdelrazak Younes]

On Wed, Mar 14, 2018 at 12:23 PM, Pavel Sanda  wrote:

> Abdelrazak Younes wrote:
> > Thanks, I sometime read the devel list just for fun :-)
>
> That's a bizarre form of masochism :)
> Where do you live now, there were some rumors we might try to organize
> development meeting after the years...
>

Living close to Lausanne in Switzerland, well I guess we could organize one
here, I can book a nice meeting room for the week-end.

Abdel

Re: Windows Installer: Future Issues

[Abdelrazak Younes]

On Wed, Mar 14, 2018 at 11:14 AM, Pavel Sanda  wrote:

> Jean-Marc Lasgouttes wrote:
> > Le 14/03/2018 ?? 11:10, Abdelrazak Younes a écrit :
> >> By the way, you should definitely release now in order to get into next
> >> Ubuntu LTS release...
> >
> > AFAIU, it is too late already.
>
> 2 weeks already...
>

Too bad!


> Hi Abdel, nice to hear you again!! :)
>


Thanks, I sometime read the devel list just for fun :-)

You guys are still doing a great job, congratz for this release!

Abdel

Re: Windows Installer: Future Issues

[Abdelrazak Younes]

By the way, you should definitely release now in order to get into next
Ubuntu LTS release...


On Wed, Mar 14, 2018 at 11:05 AM, Abdelrazak Younes  wrote:

> Hi Guys,
>
> In the old days we had the Friday rule for fight... you should restore the
> tradition :-)
>
> Cheers,
> Abdel
>
>
> On Wed, Mar 14, 2018 at 7:23 AM, Jürgen Spitzmüller  wrote:
>
>> Dear all,
>>
>> I have kept calm in this debate until now, but since this is getting more
>> and more ridiculous, here is my position.
>>
>> I think (and I actually propose herewith) that we should release LyX
>> 2.3.0 now, without the Windows installer.
>>
>> It is unacceptable that one single developer holds up a major release
>> while refusing to accept (1) the majority position (actually, the position
>> of _any_ other developer besides himself) and (2) even the release
>> manager's decision.
>>
>> It seems clear that Uwe holds the view that he is the only person who
>> knows what Windows users want and need, and how the installer has to look
>> like. I am sure he has reasons to believe this, but under this condition, I
>> do not consider the Windows installer a part of this community project,
>> since a community project requires that developers accept (1) and (2)
>> above. Since this is an open source (and GPLed) software, Uwe is free to
>> release "his" installer somewhere else, in the shape and form he consider
>> "right", and he does not need to bother with our "unqualified" arguments.
>>
>> With all due respect to Uwe as a person and as a developer. But we cannot
>> proceed like this.
>>
>> Jürgen
>>
>
>

Re: Windows Installer: Future Issues

[Abdelrazak Younes]

Hi Guys,

In the old days we had the Friday rule for fight... you should restore the
tradition :-)

Cheers,
Abdel


On Wed, Mar 14, 2018 at 7:23 AM, Jürgen Spitzmüller  wrote:

> Dear all,
>
> I have kept calm in this debate until now, but since this is getting more
> and more ridiculous, here is my position.
>
> I think (and I actually propose herewith) that we should release LyX 2.3.0
> now, without the Windows installer.
>
> It is unacceptable that one single developer holds up a major release
> while refusing to accept (1) the majority position (actually, the position
> of _any_ other developer besides himself) and (2) even the release
> manager's decision.
>
> It seems clear that Uwe holds the view that he is the only person who
> knows what Windows users want and need, and how the installer has to look
> like. I am sure he has reasons to believe this, but under this condition, I
> do not consider the Windows installer a part of this community project,
> since a community project requires that developers accept (1) and (2)
> above. Since this is an open source (and GPLed) software, Uwe is free to
> release "his" installer somewhere else, in the shape and form he consider
> "right", and he does not need to bother with our "unqualified" arguments.
>
> With all due respect to Uwe as a person and as a developer. But we cannot
> proceed like this.
>
> Jürgen
>

Re: C++ "good practices" regarding constifying a function parameter?

[Abdelrazak Younes]

On 06/08/2016 21:58, Guillaume Munch wrote:

But I agree that new move functionality in C++11 is really nice and I

know that I have to unlearn the good practice I learned so many years
ago in order to use them efficiently.


The issue with c++11 move semantics is that it is an addition of a big
layer of complexity on top of the rest for backward-compatibility
reasons and that makes everything very complicated. We want to avoid
needlessly writing complicated code that few people understand.


Agreed. Indeed I've seen code with lots of lambda that is very hard to read.

I think one should think about c++11 as a new language if you really 
want to take advantage of it. auto, range loop, new algorithm, etc are 
very nice but mixing old style c++ and c++11 leads to confusing source code.



The most important thing to remember is the conclusion in part 3: pass
by const reference, unless the function needs a copy "conceptually". In
this case, you should pass by value. Pros:
* Simple and generic rule.
* Not a big change compared to what developers are used to.
* Exposes in the interface the knowledge of when passing an argument is
going to be expensive.
* In the latter case, offers to the caller the opportunity to move the
argument instead of copying it.


Sounds good.




***


In addition, now, what if we want to design a bulky class that relies on
being moved more often than being copied? It is possible to simply make
the copy explicit in the class declaration (say TexRow), as follows:

explicit TexRow(TexRow const & other) = default;
TexRow(TexRow && other) = default;
TexRow & operator=(TexRow const & other) = default;
TexRow & operator=(TexRow && other) = default;

(this defines respectively the copy and move constructors, and the 
copy and move operators, as default.)

Making the copy constructor explicit prevents implicit copies when
passing an argument. One has to explicitly move or copy. Pros:

* It forces to think about it.
* It also prevents every cases of move(obj) unexpectedly performing a
copy instead of a move.

I still have to see whether this particular use case is not redundant
with encapsulating in a unique_ptr. But I would like to suggest that
copy constructors should be made explicit when a class is designed to be
moved, if only to avoid reading code containing move(obj) and not
knowing whether it's really a move.


Sounds good as well :-)

Abdel.

Re: C++ "good practices" regarding constifying a function parameter?

[Abdelrazak Younes]

On 06/08/2016 17:04, Guillaume Munch wrote:

Le 06/08/2016 à 10:16, Abdelrazak Younes a écrit :


(1) Do not commit any part of the patch because it is so minor.


This is my preference because it doesn't bring anything and it can
create confusion for the beginner when compared with const
reference.


But I am sceptical of a code guideline that discourages documenting
the code (for instance with const) when one feels that it is appropriate.


I'd rather this guy take the time to write down a nice doxygen comment 
in the header to explain the parameter.





The C++ beginner could be tempted to add a "&" here...


If a beginner changes const into const & without understanding what they
are doing, then this hints at an issue which is different from
inexperience. I have to reject this argument.


Shit happens :-) And this kind of mistake are easily missed even by the 
careful reviewer.





The coding style should also say that function parameter shall not
be changed in the function. Create your own local copy if you need
it.



I know where this comes from, but this surely cannot be a rule anymore
since this defeats any benefit from move operators.


AFAIU move operator has zero benefits on POD, copy will happen; it only 
works on classes or containers that support it (eg vector). But to be 
honest I prefer that complex types are always using const ref or rvalue 
(|&&) |if you want to have move semantics.



I prefer the style
where a function that only works on a copy receives the argument by
value.


I prefer to choose explicitly whether to use copy or const ref :-)


Not only this is simpler to understand as a principle and in an
interface, but it leaves the compiler (and when necessary, the
programmer) the possibility of moving the argument instead of copying it.


And it can kill the performance if you pass a big variable that is not 
movable,  AFAIU (I may be wrong).


But I agree that new move functionality in C++11 is really nice and I 
know that I have to unlearn the good practice I learned so many years 
ago in order to use them efficiently.


Thanks,
Abdel.

Re: C++ "good practices" regarding constifying a function parameter?

[Abdelrazak Younes]

On 06/08/2016 14:41, Vincent van Ravesteijn wrote:
But, I guess the coding standard says that functions shouldn't be 
longer than something like half a screen. 


Exactly!

Cheers,
Abdel.

Re: Pandora's box

[Abdelrazak Younes]

Hi Guillaume,

Just my 2 cents about those recent commits:

1) Switching to C++11 thread is a good thing
2) All these #if (gcc 4.6) are uglyfying the code considerably, you 
should enter C++11 with 2 steps or just leave it.


Thanks,
Abdel

On 31/07/2016 19:38, Guillaume Munch wrote:

Hi list,


By touching upon the problem of static variables and threading in LyX
(see my patch at ), I
have the impression that I opened Pandora's box.

I just committed a series of patches that fixes "FIXME thread" in cases
where c++11 gives an easy solution for common problems, with some
explanations which you may enjoy.

Here's an additional patch that uses thread_local instead of static to
fix, I think, threading issues for some of the cases (e.g. when caching
some value for optimisation purpose). But I'd like to hear some comments
before committing.

For other "FIXME thread" issues, either the solution is more complex, or
using statics is inappropriate altogether (I think). Is there a plan to
get rid of these?

Also, when reviewing the use of non-const static variables, I found many
cases where thread-safety was not obvious to me but no "FIXME thread"
comment was present. Is it known whether the remaining static variables
without "FIXME thread" are thread-safe?

Ideally, I think it would be nice to only use statics when necessary,
and use the new tools provided by C++11 (see my recent commits and the
attached patch).


Guillaume

Re: C++ "good practices" regarding constifying a function parameter?

[Abdelrazak Younes]

Hi Scott,

Too late already but my 2 cents below :-)

On 27/07/2016 02:54, Scott Kostyshak wrote:

The attached patch constifies a function parameter. My question is
whether this patch causes more pain to other developers than it does
good to the code.

The patch modifies a header that is included in many of our .cpp files,
so will cause a significant amount of recompilation.

I think I will come across this scenario in the future so I am curious:
what are your preferences?

(1) Do not commit any part of the patch because it is so minor.


This is my preference because it doesn't bring anything and it can 
create confusion for the beginner when compared with const reference. 
The C++ beginner could be tempted to add a "&" here...


I think it was in the coding style document somewhere that POD parameter 
(except big structure of course) should be passed by copy.


Conclusion: I'd prefer the coding style to actually forbids this 
actually :-)
The coding style should also say that function parameter shall not be 
changed in the function. Create your own local copy if you need it.


Thanks,
Abdel.

Re: One official build system?

[Abdelrazak Younes]

On 04/06/2016 10:18, Georg Baum wrote:

Abdelrazak Younes wrote:


Hi Guys,

Funny to discover that the same discussion is coming back every couple
of years :-)

I am not surprised at all, maintaining two build systems with such a small
amount of developers is simply stupid.


I agree.


The main disadvantage of GLOB is that it can mess up your build if you
let in the source tree some files that was renamed for debugging or
development purpose. Personally I never do that because git branching
and stashing are so good that it is much simpler to use git instead of
manual renaming; but I can fully understand that you are not comfortable
with that.
For renaming files or adding new files I would prefer to handle that
completely in git as well. However, it does not work. If I add a new file
and then stash the changed away, git adds the new file to the stash, but
does not delete the one in the local working tree, so when I pop from the
stash again I get a conflict. Therefore, I do not add new files to the
stash, and then I can easily move around.


In this case branching is the solution, not stashing indeed.




1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups
now (both folder hierarchy and file/class names)
3) Switch file listing mode without GLOB.

Switching to cmake first and some time later from GLOB to explicit file
listing would create a huge amount of work, since you would need to recreate
all file lists from scratch.


Creating a list with all files in the tree is very simple... You can 
even automate that with CMake I think.


Anyway, those are details I think, the important thing to decide is to 
switch or not.


Thanks,
Abdel.

Re: One official build system?

[Abdelrazak Younes]

Hi Guys,

Funny to discover that the same discussion is coming back every couple 
of years :-)


On 03/06/2016 22:22, Jean-Marc Lasgouttes wrote:

Le 03/06/16 à 18:42, Richard Heck a écrit :

Same here. I am used to autotools, so I use it.


I have reservations about cmake, but I would have some against 
autotools if I was not used to it already. All I ask from cmake is 
that it does the right think (i.e. what we advise people to do) by 
default (both for release and developer versions)


That's very much up to you guys to tell cmake to do the right thing. I 
believe that Kornel has done a lot of work already to



without having to use variables in capital letters that hurt my fingers.


CMake commands can be used lower or upper case. I personally always use 
lower case.




For the rest, I trust that the problems will vanish with time.


I think the only point to discuss is the GLOB functionality. AFAIR Georg 
and you are against it and I can understand why. The advantage of GLOB are:

1) You do not have to maintain the list of files
2) You can move and rename the files from one folder to the other very 
easily.


The main disadvantage of GLOB is that it can mess up your build if you 
let in the source tree some files that was renamed for debugging or 
development purpose. Personally I never do that because git branching 
and stashing are so good that it is much simpler to use git instead of 
manual renaming; but I can fully understand that you are not comfortable 
with that. Another con against GLOB is that we cannot control what the 
user does and there are some chances that he mess up with his source 
tree; in the best case this would just break compilation; in the worst 
case this would introduce very subtle bugs. IMHO, even this


Here is my humble advice to you guys:

1) Switch to CMake now
2) Take advantage of GLOB to do the much needed file hierarchy cleanups 
now (both folder hierarchy and file/class names)

3) Switch file listing mode without GLOB.

Hope that helps,
Abdel.

PS: for 2) I can dig out a proposal I made quite some years ago if you 
are interested

Re: [ANNOUNCE] LyX 2.2.0 Released

[Abdelrazak Younes]

Congratulations guys!!!

It feels really good to know that LyX is still in development after so 
many years :-)


I look forward to trying the new version...

Abdel


On 28/05/2016 01:55, Scott Kostyshak wrote:

Public release of LyX version 2.2.0


We are proud to announce the release of LyX 2.2.0.

With this release, LyX celebrates 20 years of existence. The 2.2 series
has a rich set of new features compared to the current stable series.

LyX 2.2.0 is the culmination of two years of hard work. An overview
of the new features can be found here:
   http://wiki.lyx.org/LyX/NewInLyX22

You can download LyX 2.2.0 from https://www.lyx.org/Download/.

For Windows users, if you installed a pre-release of LyX 2.2.0, you
should uninstall that version before installing this newer release.

We hope you will enjoy the result!

The file lib/RELEASE-NOTES lists some known issues and problems compared
to the current stable releases (LyX 2.1.x). We strongly recommend that
packagers of LyX on various platforms and distributions read this file.

As with any major release, this one comes with a lot of new features but
also some bugs. If you think you have found a bug in LyX 2.2.0, either
email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
or open a bug report at http://www.lyx.org/trac/wiki/BugTrackerHome.

If you have trouble using LyX or have a question, consult the
documentation that comes with LyX (under Help) and the LyX wiki, which you
will find at http://wiki.lyx.org/. You can also send email to the LyX users'
list (lyx-users at lists.lyx.org).

The LyX team.
http://www.lyx.org

Re: [patch] improve error output

[Abdelrazak Younes]

Hi Georg,

Few nitpicks inline.

On 29/11/2015 18:53, Georg Baum wrote:

The investigation of bug 9139 showed that the error message we give when a
file operation fails is not too clever. The attached patch improves this. It
is still not optimal (since qt has a very limited set of error causes that
are reported), but if we want to get the real error from the OS we have to
implement it in a platform specific way.

In my experience error messages that are as exact as possible help a lot
when investigating bug reports: You need to ask less questions, since the
bug report itself will contain more information.


Fully agreed.


  OK to go in?

Georg
diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index 950..3423972 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -238,10 +238,17 @@ bool FileName::copyTo(FileName const & name, bool 
keepsymlink,
return copyTo(target, true);
}
QFile::remove(name.d->fi.absoluteFilePath());
-   bool success = QFile::copy(d->fi.absoluteFilePath(), 
name.d->fi.absoluteFilePath());
-   if (!success)
-   LYXERR0("FileName::copyTo(): Could not copy file "
-   << *this << " to " << name);
+   QFile f(d->fi.absoluteFilePath());
+   bool const success = f.copy(name.d->fi.absoluteFilePath());


if (f.copy(name.d->fi.absoluteFilePath()))
return true;


+   if (!success) {

remove


+   QString const error(f.errorString());
+   if (error.isEmpty())
+   LYXERR0("FileName::copyTo(): Could not copy file "
+   << *this << " to " << name);
+   else
+   LYXERR0("FileName::copyTo(): Could not copy file "
+   << *this << " to " << name << ": " << 
fromqstr(error));
+   }


LYXERR0("FileName::copyTo(): Could not copy file " << *this << " to " << name);
sting const error = fromqstr(f.errorString());
if (!error.empty())
LYXERR0(": " << error);



return success;


return false;

Same comments for renameTo() and moveTo()

Cheers,
Abdel.

PS: congratz to all for LyX 2.2 alpha delivery, looks very promising!

Re: Unit testing

[Abdelrazak Younes]

On 04/11/2015 14:30, Vincent van Ravesteijn wrote:

However, I would also count as advantage, if there is someone familiar with
the framework and willing to do the setup and lend a helping hand to others.
(Maybe, the toolkit with the most developers willing to work on should win.)


We have discussed this topic several times, and no one ever stood up
with a strong
preference for, or claimed to have a lot of experience with one of the
frameworks.


I have some experience with gtest, as I said, a good framework, easy to 
install and maintain.


Abdel.

Re: Unit testing

[Abdelrazak Younes]

On 03/11/2015 14:28, Jean-Marc Lasgouttes wrote:

Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit :

Dear all,

I have prepared a unit test framework based on google-test (gtest). You
can see the commits at
http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. 


It includes gtest-1.7.0 (permitted by the license).


Hi Vincent,

What is the difference with the tests we current use (I mean the "make 
check" sort). The same but with better interface?


gtest is about unit testing. Current test framework from Georg is more 
about Blackbox testing.


In my experience blackbox tests are much easier to create, deploy and 
maintain and they are testing real use case. Blackbox testing catches 
regressions which is very good. All developers should care about 
Blackbox testing and ideally you should not create a single feature 
without the associated test.


Unit tests are good for testing all possible corner cases, focusing on a 
single function or class. In general Unit testing catches corner cases 
which are difficult to find with common use cases. The downside is that 
lazy developpers don't care about unit testing as it takes in general 
twice as much time or more to create the unit test than the time to 
create the function.


Both are good to have IMO and gtest is a good framework.

my 2 cents :-)

Abdel

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 08/10/2015 11:58, Guillaume Munch wrote:

I think that my solution is vastly superior to these proposed
alternatives that misrepresent the problem, and that I have lifted the
technical objections and the burden for translators.


I think I mostly agree with you at this point. That being said you must 
convince the others, not me :-P


Abdel.

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 08/10/2015 16:14, Stephan Witt wrote:

Am 08.10.2015 um 16:02 schrieb Jean-Marc Lasgouttes :


I have to admit that I did not understand Abdel's idea %-|

I understood it that way: to present the ellipsis character in the UI
there is no need to put that character with unicode in the source code.
It is possible to translate the sequence "..." to the character "…"
within the I18N process. I think the po files were not in the scope
of this discussion - they don't count as "source" files here.

Then it is exactly what my "hack" does. I attach it again for reference.

I think the idea was to let the translators do it manually where it is
appropriate. And to do it for english this way too.


Indeed :-)

Abdel

Re: Release manager for LyX 2.2

[Abdelrazak Younes]

On 07/10/2015 21:35, Stephan Witt wrote:

Am 07.10.2015 um 17:19 schrieb Richard Heck :


On 10/07/2015 05:08 AM, Jean-Marc Lasgouttes wrote:

Le 07/10/2015 11:04, Pavel Sanda a écrit :

Hi all,

it is very clear that we need to move forward with the release process.

After the discussion with the former and current managers we agreed that Scott
Kostyshak has our trust for the role of release manager of 2.2. He has good
understanding of the code and is constantly around to help with the development
process which makes him a perfect candidate.

He tentatively agreed to accept such responsibility.

If someone has objections to this proposal please speak now or never :)
Otherwise I wish good luck to our new release manager!

That is very good news. Scott, welcome to your new role.

Seconded. I am confident you will do a great job, Scott.

Me too. Thank you for taking the responsibility.


And me as well :-)

Cheers,
Abdel.

Re: UTF-8 in string literals and translation strings in particular

[Abdelrazak Younes]

On 07/10/2015 10:54, Jean-Marc Lasgouttes wrote:

Le 06/10/2015 22:17, Guillaume Munch a écrit :

I think you might be mixing issues. One thing is allowing to have UTF-8
string literals especially in translations, another one is deciding that
we now use … instead of ... in the interface to be consistent with Qt.


What would be worse than using ... in the UI would be to use a random 
mix of ... and … (look Ma, I managed to type it with my compose key!) 
in the UI. By doing this change, we put more pressure on our 
translators to do thing right.


An alternative would be the attached hack.


No need for any hack: Another alternative that works AFAIR and is 
cleaner IMO, english to english translation works. So, for english or 
french actually, ... can be translated to the ellipsis character.


Abdel.

Re: Understanding the painting process (André, Abdel, Lars, please read)

[Abdelrazak Younes]

On 03/10/2015 23:46, Jean-Marc Lasgouttes wrote:

Le 03/10/2015 11:50, Abdelrazak Younes a écrit :

I propose to get rid of pm::insetDimension.


pm is bv dependent; so it should nicely adapt to it containing bv.


I would think that bv::cordCache is bv dependent too...


Sure.


I do not understand your point here.

And currently something is wrong:
http://www.lyx.org/trac/ticket/9756


In this ticket you say pm is buffer dependent, this should not be the 
case. Paragraphs are Buffer dependent and pms are bv dependent, this is 
my point.
Obviously there is a bug here, is it only for SplitView? Or also for 
mutiple windows?






I think you should keep pm::insetDimension and remove bv::coordCache
completely instead. Design should be in the end like this:

* bv contains one tm
* tm contains multiple pm (tm can refer to the top InsetText or not)
* pm contains multiple insetDimension, one per inset in the paragraph.


Note that:
* coordcache also contains dimensions and positions for inner math 
insets.


MathInset should not be special in theory but, AFAIR, MathInset mixes up 
the contents and the metrics and it was too difficult to split that like 
for Paragraph and PM. This was also not fully necessary because 
MathInsets do not adapt they form depending on the bv size.
In any case, I don't see why pm could not contains dimensions and 
positions for inner math insets as well. A math inset is always inside a 
paragraph or another math inset.


* having a global bv coordinate cache allows to know where a mouse 
click lands (hovering, clicking...). It is doable with bv>tm>pm too, 
but this defeats the idea of a good old cache.


AFAIU the only difference between the global bv cache and what I am 
proposing is that the bv will ask its tm which will ask its pm which 
will ask its inset metrics. But maybe I don't follow you.





SingleParUpdate would not be necessary if all elements did their job
correctly. I also guess that SingleParUpdate assumes that there is only
one InsetText, which is of course not true. We should aim to remove this
flag.


In some cases, I still believe that it makes sense for the code to 
indicate that only the current paragraph has been changed. This is 
something that the code cannot guess without rebreaking the paragraph 
(which is expensive).


My point is that each insets or paragraph should know if something has 
changed inside it. SingleParUpdate is a top->down mechanism because the 
LFUN mechanism is always top down.
I guess it should be possible for each tm to ask its pms if it needs to 
be recalculated. That's why I think the global SingleParUpdate flag 
should not necessary.



On a related note, what is the semantics of a call to
Buffer::changed(false)? What does the caller mean?


That the buffer contents and only the content content is changed. I
guess this signal is abused for some other purpose.


I cannot parse your first sentence. 


Buffer::changed(bool) means that buffer contents and only that.

And what does it means to have a buffer which contents is changed 
without having updated metrics?


I don't remember exactly... maybe that this change is not visible and 
thus doesn't need new metrics?



Couldn't this be done on demand? I suspect this could be
made transparent by doing it in the proper metrics-fetching method.


Maybe yes. You would have to assess if the on-demand computation does
not slow down the minimal scrolling case.


I do not really see how it could slow it down.


With the pre-computed pm you don't have to compute again if you stay 
within the metrics limit of this paragraph when scrolling a bit.


Abdel.

Re: Understanding the painting process (André, Abdel, Lars, please read)

[Abdelrazak Younes]

On 02/10/2015 15:38, Jean-Marc Lasgouttes wrote:

Hello,

After a gentle push by Guillaume and a boring meeting, I decided to 
actually read the code that handles metrics computing and contents 
drawing. The result is the document below, which is available in 
development/PAINTING_ANALISYS.


It starts with questions that I had when writing the other sections of 
the document. I'd e glad if some of our old timers (and all current 
devs too, of course) could find time to read it and probe their brain 
to answer some of them. We cannot remain in a situation where we do 
not really know who paints what and when.


Will try...



Have a nice week-end.
JMarc


-- 


This file tries to describe the state of the metrics/painting
mechanism, and identify the improvements that could be made. The first
section can be read alone, although the context for them is really
given in the following ones.

Please keep this file up to date as the code evolves!!!

Abbreviations:
bv: BufferView
pm: ParagraphMetrics
tm::TextMetrics

* Questions / Ideas

These questions are consequences of the description made in the
following section. Some actions are proposed.

** Inset cache

Why do we store inset dimensions both in bv::coordCache and in
pm::insetDimension? The later one is bad when same
buffer is shown in different views.

I propose to get rid of pm::insetDimension.


pm is bv dependent; so it should nicely adapt to it containing bv. I 
think you should keep pm::insetDimension and remove bv::coordCache 
completely instead. Design should be in the end like this:


* bv contains one tm
* tm contains multiple pm (tm can refer to the top InsetText or not)
* pm contains multiple insetDimension, one per inset in the paragraph.



** SinglePar update

The flag Update::SinglePar is set in many places but never acted on.
Instead, metrics update is skipped whenever the recorded height of
current paragraph did not change and Update::Force was not specified.
Is it better to keep that (which incurs extra work) or to condition it
on Update::SinglePar? If the first solution is kept, the flag
SingleParUpdate shall be removed.


SingleParUpdate would not be necessary if all elements did their job 
correctly. I also guess that SingleParUpdate assumes that there is only 
one InsetText, which is of course not true. We should aim to remove this 
flag.




Moreover, I fail to see (yet) where the 'single' part of the program
is acted on.


Maybe in some mouse triggered action...



** Two phase drawing

Why is it necessary to set the inset positions in the drawing phase?
It seems to me that everything can be done in the metrics phase (at
least for non-math insets).


What you say seems right, maybe it was not possible to that at the time.



** Buffer::change issues

When calling Buffer::changed outside of bv::processUpdateFlags,
how do we now that the update strategy is set correctly? It is
possible to reset the strategy at the end of bv::draw. What would be
a good value? NoScreenUpdate?

On a related note, what is the semantics of a call to
Buffer::changed(false)? What does the caller mean?


That the buffer contents and only the content content is changed. I 
guess this signal is abused for some other purpose.




** Metrics outside of visible area

Why is it required to compute metrics on page above and below the
visible area?


I think this was for scroll optimization, the idea is to not to compute 
the full buffer metrics in case a small scrolling is needed.



Couldn't this be done on demand? I suspect this could be
made transparent by doing it in the proper metrics-fetching method.


Maybe yes. You would have to assess if the on-demand computation does 
not slow down the minimal scrolling case. I remember Tomaso wanted to 
compute all bv metrics in one go to improve the scrolling time; 
computing small amount of metrics above and below visible area was seen 
as a good subjective compromise I guess.




** What happens with FitCursor when the cursor is already OK?

In this case, we invoke Buffer::change(false) with drawing disabled,
which means that the paint machinery is invoked to update inset
positions. Why is this necessary at all?


Maybe for Mouse Over? In order to draw the visible hints like the 
corners around the insets or the completion arrow?




** Merging bv::updateMetrics and tm::metrics

While the full metrics computation tries hard to limit the number of
paragraphs that are rebroken, the version that is used for inner inset
does not try any such optimization. This can be very bad for very tall
insets. How difficult would it be to re-use the bv::updateMetrics logic?


We should, definitely. And I think this was my plan actually at the time:
* transfer all the logic of bv::updateMetrics to tm.
* Main InsetText should not be special.




* Two phase drawing

There are two parts to drawing the work area:

 + the metrics phase computes the size of insets a

Re: About the rowpainter2 branch (testers, have a look!)

[Abdelrazak Younes]

On 23/07/2015 16:45, Jean-Marc Lasgouttes wrote:

Le 23/07/2015 16:29, Richard Heck a écrit :

I wonder how bad this will be. In practice, people do not actually use
that many different words when writing. Probably no more than a few
hundred, and a couple thousand, at most.


It is not a problem of words, it is a problem of lines of text. For 
example, for displaying this previous sentence while typing it, I have 
to evaluate the length of


I
It
It_
It i
It is
It is_
It is n
[... lots of entries ...]]
It is not a problem of words, it is a problem of lines of te
It is not a problem of words, it is a problem of lines of tex
It is not a problem of words, it is a problem of lines of text
It is not a problem of words, it is a problem of lines of text.

These strings will remain forever in the map, and I will never need 
them anymore.


Easy way out (IIUC): Don't use the cache in the currently edited row or 
even the 2 rows after the current row in the current paragraph to cope 
with automatic justification.


Abdel

Re: Failure to compile lyx with gcc 5.1 with the new ABI

[Abdelrazak Younes]

On 09/05/2015 11:39, Jean-Marc Lasgouttes wrote:

Le 09/05/2015 09:30, Abdelrazak Younes a écrit :

Now with modern compilers and STL,  is much cheaper...


Do you have a reference for that?


My own experience + just some article that I read about gcc's and 
clang's STL minimizing the interdependency between headers... I'll try 
to find them again.


Just try it: building a simple file with  usage is intantaneous 
with gcc > 4.7. My experience tells me that there hundred things to 
optimize in your project in general before STL inclusion becomes the 
bottleneck.


Abdel.

Re: C++ question about auto_ptr

[Abdelrazak Younes]

On 09/05/2015 11:37, Jean-Marc Lasgouttes wrote:

Le 09/05/2015 09:18, Abdelrazak Younes a écrit :

On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote:

With C++11, auto_ptr is deprecated and we get warnings.

I am trying to see how we can get rid of it. unique_ptr is new to
C++11, so I'd rather avoid that.


Why that?
unique_ptr is supported since gcc 4.4 released in 2009:


We just have to check that this does not require to be in C++11 mode.


I guess it does.


Or we could decide to make C++11 the default.


Exactly my point ;-)




But quite frankly C++11 is very nice and moving to gcc 4.7 would enable
almost full C++11...; "auto" for example would improve the readability
of the code significantly. C++11 thread are quite nice as well if you
want to get rid of Qt thread in the core.


I agree that C++11 is very desirable. But releasing 2.2 soon is even 
more desirable.


Sure.

Abdel.

Re: [LyX/master] Fix build with GNU libstdc++ C++11 ABI

[Abdelrazak Younes]

On 08/05/2015 22:03, Jean-Marc Lasgouttes wrote:

Le 08/05/2015 21:19, Georg Baum a écrit :

commit 51cc8aa9f6b784f806b1d9cc97fe0749ffac29af
Author: Georg Baum 
Date:   Fri May 8 21:12:42 2015 +0200

 Fix build with GNU libstdc++ C++11 ABI

 The GNU libstdc++ that ships witch gcc 5 can be used with the
same ABI as
 older versions, or with a new ABI which is conformant to the
C++11 standard.
 LyX did not build if the latter was used:

https://kojipkgs.fedoraproject.org//work/tasks/1267/9651267/build.log

 This is now fixed by detecting the ABI version and disabling the
wrong forward
 declarations. At the same time, STD_STRING_USES_COW is switched
off for the
 C++11 ABI version, because the std::basic_string implementation
is now C++11
 conformant. Since the GNU libstdc++ can also used by other
compilers such as
 clang, we must not test for the compiler version.


Good job :) BTW, we have a problem with clang in Ubuntu 15.04. THe boost
1.55 that ships with ubuntu crashes with clang 3.6. There is not much we
can do about it, except maybe upgrading our local copy of boost.


Or removing boost ;-)

Abdel.

Re: Failure to compile lyx with gcc 5.1 with the new ABI

[Abdelrazak Younes]

On 08/05/2015 21:24, Georg Baum wrote:

José Matos wrote:


While testing what packages failed with the new ABI one of the cases is
LyX (2.1.3), the first builder to fail was the x86_64 one and this is why
this message refers to it:

https://kojipkgs.fedoraproject.org//work/tasks/1267/9651267/build.log

The failures start at the begin, so there is no need to go down to find
the culprit.

Any idea about what is wrong here?

The forward declarations in src/support/strfwd.h were wrong. I fixed this by
not using the forward declarations in C++11 mode and including 
instead. Feel free to adapt the forward declarations if you prefer that, the
configure machinery is now in place.


I think this is the correct fix.

IIRC, the idea at the time with strfwd.h (done by André) was to reduce 
compile time and it worked like a charm with the compilers at that time. 
Now with modern compilers and STL,  is much cheaper...


So IMO you should just remove strfwd.h and include string/docstring 
directly when needed.



  I hesitated to include libstdc++
interna in LyX sources, therefore I did not do it myself.


Don't do that, not good for maintenance.

Abdel.

Re: C++ question about auto_ptr

[Abdelrazak Younes]

On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote:

With C++11, auto_ptr is deprecated and we get warnings.

I am trying to see how we can get rid of it. unique_ptr is new to 
C++11, so I'd rather avoid that.


Why that?
unique_ptr is supported since gcc 4.4 released in 2009:

https://gcc.gnu.org/gcc-4.4/changes.html

I guess this is old enough...

But quite frankly C++11 is very nice and moving to gcc 4.7 would enable 
almost full C++11...; "auto" for example would improve the readability 
of the code significantly. C++11 thread are quite nice as well if you 
want to get rid of Qt thread in the core.




I have many places like in the patch below. Is there a reason why I 
should keep the auto_ptr instead of a naked pointer?


In this particular example no real advantage IMO.


What is it good for?


Mainly avoid memory leak for incautious programmers :-)

Abdel.

Re: [LyX/master] Grr...

[Abdelrazak Younes]

On 16/03/2015 14:29, Juergen Spitzmueller wrote:

commit 066d6a9cfb3936c61b514d085df01dd6835c784a
Author: Juergen Spitzmueller 
Date:   Mon Mar 16 14:30:02 2015 +0100

 Grr...


By the way, we use at works clang-format for coding style formatting. I 
am confident that all LyX rules can be enforced with this tool. This is 
a dream tool, try it


Abdel.

Re: new compiler warnings in master

[Abdelrazak Younes]

On 18/03/2015 11:39, Jean-Marc Lasgouttes wrote:

Le 18/03/2015 08:30, Uwe Stöhr a écrit :

Within the last 2 weeks a commit lead to these new compiler warnings:
(The same that I constantly report here. I am wondering why the appear
so often with recent commits.)


The warnings should be gone now. Please confirm.

THis uses integer arithmetic now and therefore Abdel's port to 
Raspberry should become snappier :)


Well, I hope that, by the time I come back to LyX development, Raspberry 
will not support already 128 floating point arithmetic :-)


Cheers,
Abdel.

Re: [patch] LyX logo logoification

[Abdelrazak Younes]

On 15/03/2015 18:29, Jean-Marc Lasgouttes wrote:

Le 15/03/15 08:44, Abdelrazak Younes a écrit :

Comments?


You use lots of hardcoded constants nobody except you will understand 1
month from now, and not even you 1 year from now :-P


What is the LaTeX source code good for?


I didn't know that... I am not literate in Latex as you may know :-)



I added some documentation, although I am not sure that it will help 
you more.


It helped me understand the roots of the code, indeed. And I think this 
reference is valuable in the code, thanks!




It helped me to notice a couple oversights. Thanks.


Thanks.




At least those are used 4 times and should use meaningfully named
constants: 0.16667 and 0.125.


These are just numbers: 1/6em and 1/8em. Ask Knuth for their proper 
names.


Didn't know that. Still ugly though :-)





Nitpick: 0.16667 ~= 1/6 so if you want to be more accurate you'd better
use division per 6.


Being accurate in this case is doing what TeX does.


I see.



Nitpick 2: You are using floating point calculation while you could
fixed point calculation easily. Not a problem on PC but on some ARM
systems (eg older Raspberry Pi).


As Knuth wrote, "premature optimization is the root of all evil".


Which is maybe the reason why LateX code is so ugly. I guess LaTeX has 
some special way to do fixed point calculation based on floating point 
representation, hasn't it?


Thanks,
Abdel.

Re: [patch] Prefer svg icons

[Abdelrazak Younes]

Hi Enrico,

On 16/02/2015 15:21, Enrico Forestieri wrote:

The attached patch let LyX use svg icons (if they exist) in preference
to png ones. The svg icons automatically scale to the wanted dimension
and the patch introduces 2 more resolutions (huge and giant icons) that
should be useful to people with hires displays.

Some svg icons were already added by Jürgen to the lib/images/svg subdir.
However, they are not seen there and should be copied in the normal places.
To this end, I also attach a shell script that symlinks them properly.
The script works like a toggle, i.e., the first time it is launched
the symlinks are created. When it launched a second time, the symlinks
are removed.

If no svg icons exist, LyX will use pngs, as usual. In my testing,
it turns out that some svgs are problematic and give warnings on
the console while they are loaded. Apart from that, everything seems
to work for me, but you never know, so I am asking for comments before
committing.


One general comment from my old souvenirs:

Qt supports SVG tiny standard and, IIRC, there were talk to deprecate 
that support in some 5.X version.


At some point in the past, we did mostly the same thing as your patch 
(not sure if this was André, Peter or me); we also had all icons 
embedded in resource for faster loading and easier distribution. IIRC 
there were some valid arguments that got this patch  rejected at the end 
so you might want to look at the archives.


But I like your patch ;-)

Cheers,
Abdel

Re: [patch] LyX logo logoification

[Abdelrazak Younes]

On 13/03/2015 15:21, Jean-Marc Lasgouttes wrote:

Le 13/03/2015 12:10, Jean-Marc Lasgouttes a écrit :

In this patch, I change our new LyX logo inset to look like the real
thing. Georg, is there a reason why your chose not to follow this route
(or only lack of time/motivation).

Also, I am not sure that the Color_special color is the best choice (try
to load the Intro manual, for example). Would it be a problem to use
normal color once it is clear that the logo is something special, not
plain text?


With this new patch all logos are logoified and the color is the 
normal plain one.


Comments?


You use lots of hardcoded constants nobody except you will understand 1 
month from now, and not even you 1 year from now :-P


At least those are used 4 times and should use meaningfully named 
constants: 0.16667 and 0.125.


Nitpick: 0.16667 ~= 1/6 so if you want to be more accurate you'd better 
use division per 6.
Nitpick 2: You are using floating point calculation while you could 
fixed point calculation easily. Not a problem on PC but on some ARM 
systems (eg older Raspberry Pi).


My 2 cts of the year :-)

Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 23/11/2014 22:21, Richard Heck wrote:

On 11/23/2014 02:38 PM, Jean-Marc Lasgouttes wrote:

Le 23/11/2014 18:34, Abdelrazak Younes a écrit :

This string might be modified by some class in main thread while being
read at the same time by a buffer clone in the export thread. If the
memory reserved by basic-string is big enough we should be fine but if
not basic_string will allocate another chunk of memory and delete
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor
(basic_string::reserve() should exist).
2) protect babel_ with a mutex.


This variable is normally not modified after startup. It is as const 
as can be.


Yes, that's what's so puzzling: This is only being read.


Then there is a good chance that Georg is fully right... But I still 
feel there's some other reason...


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 22/11/2014 23:01, Richard Heck wrote:

On 11/22/2014 03:19 AM, Abdelrazak Younes wrote:

On 20/11/2014 21:04, Georg Baum wrote:

I don't think so in this case. The crash happens because internal
std::basic_string members are corrupt, and it is almost always a string
created from Language::babel_. Furthermore, I was not able to 
reproduce the

crash after changing

std::string const & babel() const { return babel_; }

to

std::string const babel() const { return babel_.c_str(); }

in Language.h (which circumvents copy-on-write).


Hum, well, maybe Language object is shared between the buffer clones? 


In BufferParams.h:
///
Language const * language;


Ahah...



That could well explain the issue... babel_ is accessed at the same 
time between 2 threads which creates a race condition.


So my solution would be to protect the Language object through a mutex.

If I am right then this crash is due to a flow in our design, not in 
the STL string.


I'm not as well informed as you and others about these sorts of 
issues. Why would
simply having two threads reading the babel_ string at the same time 
cause this sort
of problem? We shouldn't have write access to the language object from 
the Buffer.


This string might be modified by some class in main thread while being 
read at the same time by a buffer clone in the export thread. If the 
memory reserved by basic-string is big enough we should be fine but if 
not basic_string will allocate another chunk of memory and delete 
previously used one. So, if this is really the culprit, 2 choices:
1) easy one: reserve some memory for babel_ in Langage ctor 
(basic_string::reserve() should exist).

2) protect babel_ with a mutex.

In any case, one should audit this Language class for thread safety. 
Same thing for BufferParams if this is shared between buffers.


Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

On 20/11/2014 21:04, Georg Baum wrote:

I don't think so in this case. The crash happens because internal
std::basic_string members are corrupt, and it is almost always a string
created from Language::babel_. Furthermore, I was not able to reproduce the
crash after changing

std::string const & babel() const { return babel_; }

to

std::string const babel() const { return babel_.c_str(); }

in Language.h (which circumvents copy-on-write).


Hum, well, maybe Language object is shared between the buffer clones? 
That could well explain the issue... babel_ is accessed at the same time 
between 2 threads which creates a race condition.


So my solution would be to protect the Language object through a mutex.

If I am right then this crash is due to a flow in our design, not in the 
STL string.




I also did tests with valgrind. memcheck reported an unrelated error in
LaTeX log file parsing which I fixed, and helgrind pointed at
std::basic_string (see log in trac). I am not 100% sure if the helgrind log
does not contain false positives, but it does at least not contain any hints
to other causes of the problem.


For me the fact that this is all related to the Latex exports means that 
the latex export functions are not thread safe and we should work on that.






Why not compile with c++11 option? I guess basic_string won't do
copy-on-write if compiled this way?

Because the GNU libstdc++ is not conformant in this aspect: It uses copy-on-
write even with C++11.


Hum, I thought libstc++ was mostly about iostream and basic_stream is 
coded all in template header?



Well, IIRC I developed buffer cloning and initial threaded export using
Linux :-)
Maybe Peter Kuemmel continued the work under Windows but I don't think
so...

Sorry, then my memory was wrong. I thought that Vincent developed this.

BTW, I would love to be proven wrong, because I find this issue rather
scary, but up to now I did not find any convincing argument, so please try
harder;-)


I tried ;-)

Abdel.

Re: Thread problems with std::basic_string and GNU libstdc++

[Abdelrazak Younes]

Hi Georg,

Warning: I haven't read LyX source code for a long long time :-)

On 19/11/2014 22:43, Georg Baum wrote:

Hi,

while investigating http://www.lyx.org/trac/ticket/9336 I found out a
fundamental problem with our multithreaded export: The GNU libstdc++ gives
only a relatively weak thread-safety guarantee about std::basic string. It
is not completely thread-safe in the POSIX sense. The reason for this lies
in the employed copy-on-write technique, which is not used in other STL
implementations such as the one in clang or MSVC. It is even explicitly
forbidden in the new C++11 standard, and the gcc folks already acknowledged
that they will get rid of it, but since this is an ABI incompatible change
they want to wait until they have several such changes to do all in one go.
For details please see the excellent gcc bug report by James Kanze (who is a
C++ expert) at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334,
especially https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334#c21, which
describes almost exactly the situation we have with the document language.

This looks all rather theoretical, but in practice it means that it is quite
easy to produce crashes if you use LyX built with #define EXPORT_in_THREAD 1
and gcc, and start an export, depending on the document (master-child setups
seem to be much more vulnerable). The thing which seems to be most affected
is Language::babel_, which is copied a lot, but problems could arise from
all std::string and docstring variables.


I am not questioning your reasoning but I think STL thread safety 
limitation has limited impact in our case. AFAIR, the Buffer is cloned 
in in the current and main thread so we have no race condition here. 
After that the cloned buffer shares nothing with the original Buffer and 
can thus be used safely in another thread.





What do we do now? I can think of several alternatives:

1) Do nothing, because my findings are incorrect. I don't believe that of
course, but I would appreciate it if somebody would try to find flaws in my
reasoning.


I believe that there could be many reasons that could cause a crash 
before incriminating the stl string, etc:

* Gui elements (message passing?)
* Graphics preview elements



2) Disable EXPORT_in_THREAD if GNU libstdc++ is found. This is an easy and
safe solution, with the disadvantage that it removes a feature (but I think
that this is much better than risking crashes).

3) Derive an own class lyx::basic_string from std::basic_string which
circumvents copy-on-wrtite in the copy-constructor and assignment operator
by creating the copy from c_str(). Then use it

namespace lyx {
typedef basic_string docstring;
typedef basic_string string;
}

and replace all occurances of std::string with lyx::string. This would of
course need a lot of testing, but I believe it could work.

4) Do not use std::basic_string at all, but an own implementation which
could be stolen from STLport or clang (if the licenses permit that and are
compatible to the GPL, I did not check that). However, I believe that this
would create lots of interface problems with other libraries.


Does anybody see any other solution? I think for the stable branch we do not
really have any choice and need to implement 2).


Why not compile with c++11 option? I guess basic_string won't do 
copy-on-write if compiled this way?





The other question is: What can we learn for the future? AFAIK
EXPORT_in_THREAD was developed on windows, and it was probably well tested
on that platform. However, one basic lesson to learn is that such important
infrastructure changes need thorough testing on all supported platforms, and
I don't think this did happen in this case. Despite qt hides many
differences for us there are still a lot of platform specific issues left.


Well, IIRC I developed buffer cloning and initial threaded export using 
Linux :-)

Maybe Peter Kuemmel continued the work under Windows but I don't think so...

Thanks Georg, that was nice to discuss this.

Abdel.

Re: [LyX/master] Prevent accidental usage of wrong copy constructor

[Abdelrazak Younes]

On 14/11/2014 18:48, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 11/11/2014 20:58, Georg Baum a écrit :

commit 8f93600d3fa8182ba43973075cf37e7ecb2be8d3
Author: Georg Baum 
Date:   Tue Nov 11 07:22:14 2014 +0100

  Prevent accidental usage of wrong copy constructor

Is this what we use boost:noncopyable for in some places? It would be
nice to keep the same form in all these places.

This used to be boost::noncopyable a long time ago, but IIRC this is now
considered evil, because it pulls in a header just for very little benefit.

Please correct me if I am wrong, I'll change this if that is the case.


I think you are right.

Nitpick: private stuff is at the end of the class not at the top.

Abdel.

PS: I got some nice ideas today about teletext charset handling thanks 
to the work we did together on Unicode ;-)

Re: cmake warnings

[Abdelrazak Younes]

On Sun, May 11, 2014 at 11:23 AM, Scott Kostyshak  wrote:

> On Sun, May 11, 2014 at 5:16 AM, Abdelrazak Younes  wrote:
> > On Sun, May 11, 2014 at 11:09 AM, Kornel Benko  wrote:
> >>
> >> >  Hunspell is installed on my system, why don't we pick that
> >> > automatically?
> >>
> >> Good question. But which one to select, if also the other are installed?
> >> There may be a reason why someone does not want a specific lib.
> >
> >
> > I would say by order of preference check hunspell, then enchant, then
> > aspell.
>
> Regardless of the order (e.g. even if Enchant is prioritized), it
> would be nice to fill in the path in Preferences > Paths so that if
> the user wants to use Hunspell all he has to do is change the
> spellchecker.
>

Indeed, AFAIR we can compile concurrent support for all 3 spellers so if
the development packages are found we should use them.

Abdel

Re: Call for testers: the features/str-metrics branch

[Abdelrazak Younes]

On Thu, May 8, 2014 at 7:01 PM, Jean-Marc Lasgouttes wrote:

> Le 08/05/14 18:45, Abdelrazak Younes a écrit :
>
>  I don't read Arabic but my wife does. I'll see if I can find time over
>> the week-end to compile your branch.
>>
>
> Thanks, you're a sweetheart. I already know that cursor positioning is
> wrong, but I am not sure yet how to make this work. If smething looks
> wrong, I'm interested too to know whether it is a regression wrt master or
> 2.0.x.
>

As a first trial cursor positioning seems correct. I don't have much time
to check against lyx2.0 but I copied and paste from the web (Firefox) to
LyX and LibreOffice.
Main visible issue is with letter LAM when combined with ALIF.

LAM is "G" on the english keyboard:
ل

ALIF is "H" on the english keyboard:
ا

LAM-ALIF:
لا

Above should be correctly shown in gmail webmail, it looks like Gamma greek
letter. In LyX if shows this:


Abdel







>
> JMarc
>
>

Re: cmake warnings

[Abdelrazak Younes]

On Sun, May 11, 2014 at 11:09 AM, Kornel Benko  wrote:

> > > You do miss some.
> > > LYX_CPACK, LYX_ASPELL, LYX_ENCHANT, LYX_HUNSPELL.
> > >
> > > (If you don't use CPACK then at least use LYX_INSTALL option)
> > >
> >
> >  Hunspell is installed on my system, why don't we pick that
> automatically?
>
> Good question. But which one to select, if also the other are installed?
> There may be a reason why someone does not want a specific lib.
>

I would say by order of preference check hunspell, then enchant, then
aspell.

Abdel.

Re: Where is my menubar?

[Abdelrazak Younes]

On Sun, May 11, 2014 at 7:03 AM, Scott Kostyshak  wrote:

> On Sun, May 11, 2014 at 12:54 AM, Scott Kostyshak 
> wrote:
>
> > For me, toggling fullscreen on and off fixes the problem:
> > lyx -x "command-sequence ui-toggle fullscreen; ui-toggle fullscreen"
>
> Or more simply:
> lyx -x "ui-toggle menubar"
>

That works, thanks!

Abdel

Re: cmake warnings

[Abdelrazak Younes]

On Sun, May 11, 2014 at 12:22 AM, Kornel Benko  wrote:

> Am Samstag, 10. Mai 2014 um 22:26:24, schrieb Abdelrazak Younes <
> you...@lyx.org>
> > On Sat, May 10, 2014 at 9:50 PM, Kornel Benko  wrote:
> >
> > > Am Samstag, 10. Mai 2014 um 18:32:13, schrieb Abdelrazak Younes <
> > > you...@lyx.org>
> > > > Hi guys,
> > > >
> > > > Just checked out feature/str-metrics and I got  some warning when
> running
> > > > cmake:
> > > >
> > > > CMake Warning (dev) at src/CMakeLists.txt:106 (add_executable):
> > > >   Policy CMP0028 is not set: Double colon in target name means ALIAS
> or
> > > >   IMPORTED target.  Run "cmake --help-policy CMP0028" for policy
> details.
> > > >   Use the cmake_policy command to set the policy and suppress this
> > > warning.
> > > >
> > > >   Target "lyx2.2" links to target "Qt5::Concurrent" but the target
> was
> > > not
> > > >   found.  Perhaps a find_package() call is missing for an IMPORTED
> > > target,
> > > > or
> > > >   an ALIAS target is missing?
> > > > This warning is for project developers.  Use -Wno-dev to suppress it.
> > >
> > > I don't see it. But I don't have Qt5 anyway.
> > >
> >
> > I use Qt4.8 but Qt5 is also installed I think but only the runtime not
> the
> > devel package.
>
> Maybe this is the cause of the warning
> 'Target "lyx2.2" links to target "Qt5::Concurrent"',
> Could you install the Qt5 devel?
>

I can't at this point for other project reasons, sorry.



> Please notice that I am guessing only and cannot verify.
>
> > > Could you display the command arguments of add_executable on line 106?
> > >
> > > message(STATUS  ${_lyx}
> > > ${WIN32_CONSOLE}
> > > ${LYX_BUILD_BUNDLE}
> > > ${lyx_sources}
> > > ${lyx_headers}
> > > ${vld_files}
> > > ${FILE_RC}
> > > ${lyx_info_files}
> > > ${lyx_cmake_files}
> > > ${OSX_BUNDLE_FILES}
> > > )
> > >
> > > To see, where is the colon inserted?
> > >
> >
> > Here it is:
> >
>
> Nothing special in it. Especially no colon ':'.
> Are you using new cmake ( >= 3.0)?
>

Yes, I forgot I was using a development version, sorry about that:
  3.0.20140324-g4f419


> > > >
> > > > By the way, I just run "cmake .." without any argument, is this good
> > > enough
> > > > those days?
> > >
> > > No. But since some values will be used from cache, so it may fit.
> > >
> >
> > This was a fresh checkout, so no cache. My question was about make sure I
> > don't miss important cmake definitions.
>
> You do miss some.
> LYX_CPACK, LYX_ASPELL, LYX_ENCHANT, LYX_HUNSPELL.
>
> (If you don't use CPACK then at least use LYX_INSTALL option)
>

 Hunspell is installed on my system, why don't we pick that automatically?

Thanks,
Abdel.

Re: cmake warnings

[Abdelrazak Younes]

On Sat, May 10, 2014 at 9:50 PM, Kornel Benko  wrote:

> Am Samstag, 10. Mai 2014 um 18:32:13, schrieb Abdelrazak Younes <
> you...@lyx.org>
> > Hi guys,
> >
> > Just checked out feature/str-metrics and I got  some warning when running
> > cmake:
> >
> > CMake Warning (dev) at src/CMakeLists.txt:106 (add_executable):
> >   Policy CMP0028 is not set: Double colon in target name means ALIAS or
> >   IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
> >   Use the cmake_policy command to set the policy and suppress this
> warning.
> >
> >   Target "lyx2.2" links to target "Qt5::Concurrent" but the target was
> not
> >   found.  Perhaps a find_package() call is missing for an IMPORTED
> target,
> > or
> >   an ALIAS target is missing?
> > This warning is for project developers.  Use -Wno-dev to suppress it.
>
> I don't see it. But I don't have Qt5 anyway.
>

I use Qt4.8 but Qt5 is also installed I think but only the runtime not the
devel package.


> Could you display the command arguments of add_executable on line 106?
>
> message(STATUS  ${_lyx}
> ${WIN32_CONSOLE}
> ${LYX_BUILD_BUNDLE}
> ${lyx_sources}
> ${lyx_headers}
> ${vld_files}
> ${FILE_RC}
> ${lyx_info_files}
> ${lyx_cmake_files}
> ${OSX_BUNDLE_FILES}
> )
>
> To see, where is the colon inserted?
>

Here it is:

-- 
lyx2.2/home/ayounes/devel/lyx/maingit/src/output_docbook.cpp/home/ayounes/devel/lyx/maingit/src/InsetList.cpp/home/ayounes/devel/lyx/maingit/src/Color.cpp/home/ayounes/devel/lyx/maingit/src/Language.cpp/home/ayounes/devel/lyx/maingit/src/TocBackend.cpp/home/ayounes/devel/lyx/maingit/src/ConverterCache.cpp/home/ayounes/devel/lyx/maingit/src/HSpace.cpp/home/ayounes/devel/lyx/maingit/src/LaTeXFonts.cpp/home/ayounes/devel/lyx/maingit/src/Session.cpp/home/ayounes/devel/lyx/maingit/src/CutAndPaste.cpp/home/ayounes/devel/lyx/maingit/src/PDFOptions.cpp/home/ayounes/devel/lyx/maingit/src/VSpace.cpp/home/ayounes/devel/lyx/maingit/src/factory.cpp/home/ayounes/devel/lyx/maingit/src/BranchList.cpp/home/ayounes/devel/lyx/maingit/src/DocIterator.cpp/home/ayounes/devel/lyx/maingit/src/Compare.cpp/home/ayounes/devel/lyx/maingit/src/LyXVC.cpp/home/ayounes/devel/lyx/maingit/src/InsetIterator.cpp/home/ayounes/devel/lyx/maingit/src/FuncRequest.cpp/home/ayounes/devel/lyx/maingit/src/sgml.cpp/home/ayounes/devel/lyx/maingit/src/Graph.cpp/home/ayounes/devel/lyx/maingit/src/boost.cpp/home/ayounes/devel/lyx/maingit/src/Lexer.cpp/home/ayounes/devel/lyx/maingit/src/TextClass.cpp/home/ayounes/devel/lyx/maingit/src/LyXRC.cpp/home/ayounes/devel/lyx/maingit/src/Buffer.cpp/home/ayounes/devel/lyx/maingit/src/Text2.cpp/home/ayounes/devel/lyx/maingit/src/ParagraphParameters.cpp/home/ayounes/devel/lyx/maingit/src/PersonalWordList.cpp/home/ayounes/devel/lyx/maingit/src/version.cpp/home/ayounes/devel/lyx/maingit/src/LyXAction.cpp/home/ayounes/devel/lyx/maingit/src/Length.cpp/home/ayounes/devel/lyx/maingit/src/output_plaintext.cpp/home/ayounes/devel/lyx/maingit/src/ServerSocket.cpp/home/ayounes/devel/lyx/maingit/src/output_xhtml.cpp/home/ayounes/devel/lyx/maingit/src/Text.cpp/home/ayounes/devel/lyx/maingit/src/KeySequence.cpp/home/ayounes/devel/lyx/maingit/src/rowpainter.cpp/home/ayounes/devel/lyx/maingit/src/FontList.cpp/home/ayounes/devel/lyx/maingit/src/Undo.cpp/home/ayounes/devel/lyx/maingit/src/TexRow.cpp/home/ayounes/devel/lyx/maingit/src/Spacing.cpp/home/ayounes/devel/lyx/maingit/src/Dimension.cpp/home/ayounes/devel/lyx/maingit/src/BufferParams.cpp/home/ayounes/devel/lyx/maingit/src/Mover.cpp/home/ayounes/devel/lyx/maingit/src/Format.cpp/home/ayounes/devel/lyx/maingit/src/Author.cpp/home/ayounes/devel/lyx/maingit/src/output_latex.cpp/home/ayounes/devel/lyx/maingit/src/Encoding.cpp/home/ayounes/devel/lyx/maingit/src/Intl.cpp/home/ayounes/devel/lyx/maingit/src/ParagraphMetrics.cpp/home/ayounes/devel/lyx/maingit/src/CursorSlice.cpp/home/ayounes/devel/lyx/maingit/src/Counters.cpp/home/ayounes/devel/lyx/maingit/src/Thesaurus.cpp/home/ayounes/devel/lyx/maingit/src/KeyMap.cpp/home/ayounes/devel/lyx/maingit/src/FontInfo.cpp/home/ayounes/devel/lyx/maingit/src/ErrorList.cpp/home/ayounes/devel/lyx/maingit/src/Converter.cpp/home/ayounes/devel/lyx/maingit/src/ParIterator.cpp/home/ayounes/devel/lyx/maingit/src/Layout.cpp/home/ayounes/devel/lyx/maingit/src/Paragraph.cpp/home/ayounes/devel/lyx/maingit/src/ModuleList.cpp/home/ayounes/devel/lyx/maingit/src/output.cpp/home/ayounes/devel/lyx/maingit/src/BufferEncodings.cpp/home/ayounes/devel/lyx/maingit/src/Trans.cpp/home/ayounes/devel/lyx/maingit/src/VCBackend.cpp/home/ayounes/devel/lyx/maingit/src/main.cpp/home/ayounes/devel/lyx/maingit/src/Text3.cpp/home/ayounes/devel/lyx/maingit/src/BiblioInfo.cpp/home/ayounes/devel/lyx/ma

Re: Where is my menubar?

[Abdelrazak Younes]

On Sat, May 10, 2014 at 9:36 PM, Abdelrazak Younes  wrote:

> On Sat, May 10, 2014 at 7:10 PM, Pavel Sanda  wrote:
>
>> Abdelrazak Younes wrote:
>> > Just for completeness. Ubuntu package 2.0.7 does not have this issue.
>>
>> I guess you use the unity crap, right? ;)
>> https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/619811
>>
>
> No, plain KDE. But I will try the cited workarounds in this link.
>

None of these seems to work...

Abdel

Re: Where is my menubar?

[Abdelrazak Younes]

On Sat, May 10, 2014 at 7:10 PM, Pavel Sanda  wrote:

> Abdelrazak Younes wrote:
> > Just for completeness. Ubuntu package 2.0.7 does not have this issue.
>
> I guess you use the unity crap, right? ;)
> https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/619811
>

No, plain KDE. But I will try the cited workarounds in this link.

Abdel.

Re: Where is my menubar?

[Abdelrazak Younes]

On Sat, May 10, 2014 at 6:42 PM, Abdelrazak Younes  wrote:

> Hi,
>
> Just compiled a fresh str-metrics under kubuntu 14.04 (Qt4.8) and there is
> no menubar. This is actually the same for Firefox but there I can press Alt
> key to show it. Under Lyx, nothing... Alt+F just print 'f'...
>

Just for completeness. Ubuntu package 2.0.7 does not have this issue.

Abdel

Where is my menubar?

[Abdelrazak Younes]

Hi,

Just compiled a fresh str-metrics under kubuntu 14.04 (Qt4.8) and there is
no menubar. This is actually the same for Firefox but there I can press Alt
key to show it. Under Lyx, nothing... Alt+F just print 'f'...

Abdel.

cmake warnings

[Abdelrazak Younes]

Hi guys,

Just checked out feature/str-metrics and I got  some warning when running
cmake:

CMake Warning (dev) at src/CMakeLists.txt:106 (add_executable):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "lyx2.2" links to target "Qt5::Concurrent" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target,
or
  an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at src/CMakeLists.txt:106 (add_executable):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "lyx2.2" links to target "Qt5::Concurrent" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target,
or
  an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

By the way, I just run "cmake .." without any argument, is this good enough
those days?

Abdel.

Re: Converters: Skip Qt's loadable svg function

[Abdelrazak Younes]

On 07/05/2014 09:08, Pavel Sanda wrote:

Vincent van Ravesteijn wrote:

Now I remember why I didn't do that. We might want the Qt-automatic-way as
a fallback when no custom converter is defined.


Exactly.


If user wants to have svg he has to install something to get pdf output,
so the fallback does not look critical here.


The user might want to use LyX for HTML export... or someother tools are 
able to handle SVG? This is probably good enough for a lot of people 
that doesn't use advanced SVG tools.


Anyway, from the doc: http://qt-project.org/doc/qt-5/svgrendering.html
"Qt supports the static features 
 of SVG 1.2 Tiny 
."


By the way, it seems that Qt5 has a new QtSvg module, not sure we can or 
want to use that...


Abdel.

Re: Call for testers: the features/str-metrics branch

[Abdelrazak Younes]

On 06/05/2014 11:06, Jean-Marc Lasgouttes wrote:

04/05/2014 22:14, Vincent van Ravesteijn:

When selecting the first character, I see two things:

1) the connection between characters is lost (in master this is not the
case)
2) the first character actually moves to the right on selection (while
you would expect that the rest of the word moves to the left because the
first character became wider on selection)


OK, I have an idea for having correct selections without loosing the 
Color_selectiontext enum: we could draw the complete string as 
selected and non-selected, but use clipping to make sure that only the 
right part of the selection is visible. It will be a bit tricky, but 
it is doable.


However, the question is: do we want to keep this Color_selectiontext 
thing? It makes all selection lose color, which is not very helpful. 
Therefore, we could just decide to forget about that and just use 
Color_selection for the background. Actually, I haven't found any 
wordprocessor-like application that uses a selection background color.


Pavel, Enrico, as users of weird color schemes, I need your input on 
that.


The bigger problem will be cursor positioning, but I need more 
information from people who understand Arabic writing to progress on 
that.


I just noticed that we have no Arabic document (just a farsi 
splash.lyx) in our doc. This is not very encouraging. Do we even have 
Arabic writers as users?


I don't read Arabic but my wife does. I'll see if I can find time over 
the week-end to compile your branch.


Abdel.

Re: Feature request

[Abdelrazak Younes]

On 29/04/2014 18:20, Richard Heck wrote:

On 04/28/2014 06:10 PM, stefano franchi wrote:




On Mon, Apr 28, 2014 at 4:14 PM, Tommaso Cucinotta > wrote:


On 28/04/14 19:37, Patrick O'Keeffe wrote:

I don't personally see any advantage to composing emails in Lyx.
OP suggested it because of the beautiful formatting provided by
LaTeX but HTML isn't capable of such beauty. If you need the
aesthetics, you're stuck emailing it as an attachment anyway.


Forget about beauty, this is about functionality and convenience:
copying from LyX (trunk), I can send you this (I hope you can
display it correctly, at least it shows up OK while I'm composing
it):

  * For each hosts pair ( j 1 , j 2 ) ? H × H , a set P j 1 , j 2
of interconnection paths may be available and usable, where
each path p ? P j 1 , j 2 is associated with the sequence P j
1 , j 2 ,p of its L j 1 , j 2 ,p links P j 1 , j 2 ,p ={ ( a
j 1 , j 2 ,p,1 , b j 1 , j 2 ,p,1 ), ... ,( a j 1 , j 2 ,p, L
j 1 , j 2 ,p , b j 1 , j 2 ,p, L j 1 , j 2 ,p ) } ? L .


Leaving the meaning aside, my question is: how can I write this
in Thunderbird? The only way is to attach the .lyx document, or
an export of it, and it takes just more time to do that, rather
than copy/paste.


Tommaso,

I don't know what you see in Thunderbird, but I can assure you that 
in gmail your formula is barely legible. Wouldn't it be easier to 
"typeset" it in ascii?


FWIW, it is perfect here in Thunderbird.


Indeed, perfect on both Windows and Linux. This is a killer feature for 
scientist collaboration :-)


Abdel.

Re: Copying and pasting to other apps

[Abdelrazak Younes]

On 27/04/2014 23:11, Tommaso Cucinotta wrote:

On 27/04/14 16:58, Georg Baum wrote:

If you copy something, it is put onto the clipboard in three formats: plain 
text, HTML (using the HTML export) and LyX since version 2.1. The pasting 
application is then supposed to select the most appropriate format. In your 
case something goes wrong either on LyX side or on the other side. If you start 
LyX with -dbg action it should tell you what it does.

Cool! In my case, I was simply trying with the system LyX from Ubuntu (2.0.6), 
but I just tried with trunk, and it worked perfectly indeed, including tables 
AND maths! I'm actually impressed by the maths working visually when copied 
from LyX, how is that done? I don't think there's a way one can enter maths 
natively in Thunderbird, is there?


Sound really cool indeed, I will try :-)

Abdel

Re: Feature request

[Abdelrazak Younes]

On 24/04/2014 15:08, Jean-Marc Lasgouttes wrote:

24/04/2014 15:02, Kornel Benko:
 > What is so beautiful about the typography of the .html files we 
export,

 > though?

C'mon, its not so bad. For a mail it should be OK.


Do you see an added value wrt whatever html one can produce with 
thunderbird or whatever mail client?


Disclaimer: I do only text messages, so I am not really competent :)


I used to be the same but now I use more and more formatting under 
Thunderbird instead of just writing documents. This is because people I 
work with just don't read attachments, they don't have time.
I don't care about html or enriched text but I do care about 
interoperability with other mail programs so html is the only choice here.


So my feature request would be able:
1) write in LyX
2) select and copy
3) paste as html in Thunderbird.

Maybe this is already possible.

Abdel.

Re: Feature request

[Abdelrazak Younes]

On 24/04/2014 17:02, Kornel Benko wrote:

Am Donnerstag, 24. April 2014 um 17:00:16, schrieb Kornel Benko 

Am Donnerstag, 24. April 2014 um 07:49:02, schrieb Pavel Sanda 

Kornel Benko wrote:

Html is inappropriate for email
http://www.avernus.com/~gadams/essays/20020418-html-mail.html


This is convincing. So the format for email (if ever implemented by lyx) may be 
Enriched text.

Hehe, so time to drop html part of your emails to this list ;)
P

I was not even aware of the html part. Cannot see, how to disable it from 
inside kmail.

Kornel

I think, I found it. Test only.


Waoouh! It's a relief Kornel!

:-)

Abdel.

Re: Anybody Wanna Own Some Bugs?

[Abdelrazak Younes]

On 19/04/2014 19:22, Richard Heck wrote:


Abdel has asked to be removed as default owner for the dialog and 
frontend-qt4 bugs, and I've also removed him as default owner of the 
file and menu bugs. Would anyone like to replace him? The only thing 
this really means is that you get an email when a bug in that category 
has been filed, so you can do some initial triage.


While we're at it, the current list of compoments and owners is below.
Let me know if there are any other changes you think would be 
appropriate.


Some suggestions below... in general, too many components and sometime 
not clear keyword for the user.




Richard



BiDi Support  spitz
build  lasgouttes


Split between autoconf (lasgouttes) and cmake (Kornel)


changes vfr


Rename to track-change


citation rgheck


Split between "citation&reference" (rgheck) and bibliography (Jürgen)


compare vfr


Merge with "Track-Change"


configure lasgouttes


Rename to "configure.py" to avoid confusion with autoconf


converters rgheck
cursor  lasgouttes
dialogs  nobody
docbook export  jamatos
documentation  uwestoehr
externaljrioux


Rename to "External Inset"?


file rgheck


File Management ?


font lasgouttes
frontend-qt4  nobody


Merge with "dialogs". Some items in there are related to scrolling and 
editing performance, I would move to a new "Editing" component.



general lasgouttes
insetgraphics  uwestoehr


Remove.


insets rgheck
insettext   lasgouttes


Remove.


keyboard lasgouttes
latex exportlasgouttes
layout  rgheck




literate lasgouttes


Literate Programming


lyx2lyx rgheck
lyxfunc  rgheck
lyxserver   lasgouttes
lyxtext  rgheck


Remove


master/child spitz


Multipart Document


mathed spitz


"Math Editing"


menus nobody
minibuffer  rgheck
outlinerrgheck
painter lasgouttes


Merge with new "Editing components"


pdf sanda


Export PDF


preview-latex lasgouttes
search  tommaso
selection   lasgouttes
shortcuts   uwestoehr


Merge with Dialogs


spell stwitt


Spell Checking


tabular skostysh


Table Editing


tex2lyx lasgouttes
translations  uwestoehr
undo/redo   lasgouttes


Remove


version control sanda
website  chr
windows-installer  uwestoehr
xhtml export  rgheck

Re: #7437: Assertion isDirectory() violated after importing '/a/' as plain text

[Abdelrazak Younes]

On 19/04/2014 19:25, Richard Heck wrote:

On 04/19/2014 01:17 PM, Abdelrazak Younes wrote:


If you want to remove yourself as owner of the other bugs, that is 
fairly easy to do via Batch Modify. Just select all the bugs you 
want to change and switch "Owner" to nobody.


Hum, what is " Batch Modify" ?


When you do the query, you'll see toward the bottom of the page "Batch 
Modify". It allows you to change a bunch of bugs all at once. You can 
check the bugs you want to modify in the returned list, or click the 
checkbox at the top to mark them all. You have to open the Batch 
Modify widget, then you can add various fields you want to change. 
This is how the bugs fixed in 2.0.8, for example, all get marked as 
FIXED. Obviously, you have to be careful what you change. This is not 
undoable.


Sorry but "Batch Modify" in my query page:

http://www.lyx.org/trac/query?owner=younes&status=accepted&status=assigned&status=fixed&status=fixedinmaster&status=fixedinstable&status=new&status=reopened&max=200&order=id

Maybe this only shows if you are Trac Admin?

Abdel

Re: #7437: Assertion isDirectory() violated after importing '/a/' as plain text

[Abdelrazak Younes]

On 19/04/2014 19:15, Richard Heck wrote:

On 04/19/2014 01:07 PM, Abdelrazak Younes wrote:

On 23/03/2014 13:33, LyX Ticket Tracker wrote:
#7437: Assertion isDirectory() violated after importing '/a/' as 
plain text

---+---
Reporter: gmatht@… | Owner: younes
Type: defect | Status: new
Priority: normal | Milestone: 2.1.1
Component: frontend-qt4 | Version: 2.0.0svn
Severity: normal | Resolution:
Keywords: assertion keytest |
---+---
Changes (by spitz):

* cc: spitz, rgheck (added)
* owner: lasgouttes => younes
* component: general => frontend-qt4
* milestone: => 2.1.1


Hey guys,

Could we at least modify the default owner of "frontend-qt4" to nobody?


I've removed you as a default owner of any sort of bug.


Thanks.



If you want to remove yourself as owner of the other bugs, that is 
fairly easy to do via Batch Modify. Just select all the bugs you want 
to change and switch "Owner" to nobody.


Hum, what is " Batch Modify" ?

Abdel.

Re: #7437: Assertion isDirectory() violated after importing '/a/' as plain text

[Abdelrazak Younes]

On 23/03/2014 13:33, LyX Ticket Tracker wrote:

#7437: Assertion isDirectory() violated after importing '/a/' as plain text
---+---
  Reporter:  gmatht@…   |   Owner:  younes
  Type:  defect |  Status:  new
  Priority:  normal |   Milestone:  2.1.1
Component:  frontend-qt4   | Version:  2.0.0svn
  Severity:  normal |  Resolution:
  Keywords:  assertion keytest  |
---+---
Changes (by spitz):

  * cc: spitz, rgheck (added)
  * owner:  lasgouttes => younes
  * component:  general => frontend-qt4
  * milestone:   => 2.1.1


Hey guys,

Could we at least modify the default owner of "frontend-qt4" to nobody?

Abdel.

Re: Dialog-Related Bug 8144

[Abdelrazak Younes]

On 19/04/2014 17:51, Richard Heck wrote:
Can someone who knows a bit about dialogs have a look at the patch 
attached to:

http://www.lyx.org/trac/ticket/8144
please?


Hi Richard,

I added a comment there that you should use a vector of pair of strings 
instead. The patch is not really about dialog but about the InsetListing 
parameters; one more comments: this InsetListing UI is just awful!


By the way, I am still set as default owner of dialogs and UI bugs, 
could we change that? That's 122 bugs and I don't think I will address 
them in the next couple of years, if ever :-)


http://www.lyx.org/trac/query?status=!closed&owner=younes

Abdel.

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 08/03/2014 17:20, Richard Heck wrote:

On 03/08/2014 10:31 AM, Liviu Andronic wrote:
On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic 
 wrote:
On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes  
wrote:

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, 
not database, we are not going to create a new directory for each 
new inset...
But I agree that XML is really not good for humans, we should 
switch to Json, not XML.



See related:
"JSON vs XML: How JSON Is Superior To XML"
https://www.udemy.com/blog/json-vs-xml/


For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python 


https://github.com/martinblech/xmltodict


Of course, that also means there are readily available routes of 
conversion to and from JSON, if we were using XML.


For what it's worth, I find JSON completely unreadable.


Weird :-)

Anyway, moving to XML (or Json) will be a already an excellent move; and 
the one that does the work is the one that decide! I reckon that it 
would be much easier at this point to switch to XML thanks to your hard 
work on the XHTML export. So I will support your decision in any case ;-)


That being said, I *personally* find XML much too verbose and error 
prone compared to Json if you write it with a plain text editor. Json is 
also much more compact, has nice notion of arrays and numerical values, 
etc. Also an efficient binary representation of Json is really easy to 
do and would be very valuable to optimize parsing if needed. We could 
probably also reuse the one proposed by Qt if we modify it a bit (ucs4 
versus utf16).
Last by not least, if we were to switch to Json, I would also move all 
the layout and config files to Json; but hey, there's close to zero 
chance that I find the time to do it so talk is cheap ;-)


Cheers,
Abdel.

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, not 
database, we are not going to create a new directory for each new 
inset... But I agree that XML is really not good for humans, we should 
switch to Json, not XML.


Abdel.

Re: Statusbar on fullscreen

[Abdelrazak Younes]

On 20/02/2014 00:10, Pavel Sanda wrote:

Pavel Sanda wrote:

Hi,

it seems we forbid ui-toggle statusbar in fullscreen mode for no good reason.

Please can someone on windows and mac test for me that the following patch
does not break fullscreen statusbar absence?

Hey, last appeal before commiting :)


I guess this looks reasonable. I can't really see a reason at this point 
why it was like this, sorry.


Abdel.





For testing simply switch to fullscreen and try to use menu via shortcut
and observe whether it looks as expected, namely statusbar does not appear
or flicker on the screen.

It should not, but I have very little idea what would be another reason to
include these two lines of code otherwise (Abdel?).

Pavel
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 006c7e8..8acc94a 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -3801,8 +3801,6 @@ void GuiView::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
if (isFullScreen()) {
if (menuBar()->isVisible() && lyxrc.full_screen_menubar)
menuBar()->hide();
-   if (statusBar()->isVisible())
-   statusBar()->hide();
}
  }
  

Re: On GSOC 2014 application--again

[Abdelrazak Younes]

On 06/02/2014 22:25, stefano franchi wrote:


I would like to ask, in particular, those mentors who had volunteered 
last year but whose projects were not chosen if they are still 
available. That means:


- Abdel (layout editor, toolbar customization dialogue)


Hi Stefano,

As much I would like to participate I have to say no, sorry.

Good luck!

Abdel

Re: [LyX/master] Improve beamer frame conversion: consider explicit EndFrames between two identical frame types

[Abdelrazak Younes]

On 14/11/2013 15:53, José Matos wrote:

On Monday 11 November 2013 09:16:23 Juergen Spitzmueller wrote:

 Improve beamer frame conversion: consider explicit EndFrames between two 
identical frame types

Thank you, thank you, thank you. :-)

That was on my todo list for some time but now that David has arrived (12 
October)


Hey José, congratz to you and all the family :-)


  my free time is gone for a while. :-)


Minimum 5 years, still counting... if I compare with my own experience :-)

Cheers,
Abdel.

Re: 2.1.0 Blocker

[Abdelrazak Younes]

On 10/10/2013 23:12, Georg Baum wrote:

Vincent van Ravesteijn wrote:


The other difference I noticed is that on Cygwin and Solaris I get

\renewcommand instead of \newcommand. That is, applying your patch,
on Debian exporting from the GUI or from command line, produces the
same result, but lyx segafaults on exit.
On Cygwin and Solaris, exporting from the GUI changes \newcommand
into \renewcommand, but lyx quits normally.
The joy of multithreading, I suppose.


I guess the problem is that the class MacroData has a lot of mutable
variables that are being changed from const metrics() and write()
functions.

Yes, this is likely. Basically, all these changes are only needed for the
lazy macros which are created in Buffer.cpp:3229. There is even a FIXME
comment by Abdel asking why a full macro is not used. After reading the code
a bit I have to admit that it is quite confusing. Also other parts of the
macro machinery ignore the constness concept where ever needed.


AFAIR I wanted to merge the macro update machinery with the buffer/toc 
update ones...


Abdel.

Re: GSoC 2013: OutlineView and CorkboardView - ideas and questions

[Abdelrazak Younes]

On 13/05/2013 16:52, Ashley Shan wrote:

Dear community,

So I have been working with Rob on the non-linear writing project for 
a week already, and I'm focusing on implementing the corkboard 
graphics Ui. We planned to implement it using the graphic view 
framework, but I tried QML and think it's really cool. I want to hear 
from the community to what degree should I use QML in corkboard UI. I 
was planning to use QGraphicsItem for the card, QGraphicsScene for the 
board, and QGraphicsView for the view, and integrate them into the 
document model later; right now, I'm thinking of using QML for the 
entire UI part, using a GridView component for the board, but I'm not 
sure whether it's preferable in the long run and whether the document 
model can make use of the GridView component.


QML is only fully available since Qt 4.8. I guess it would be OK to use 
it if it is optional. But I fear the general look of feel of it will not 
be nice when mixed with QWidget; for example I don't know if you can 
embed a QML scene inside a QWidget. With QGraphicsView this is fully 
supported.




Also, I'm still very confused about using drag and drop; could anyone 
point to me some good resources to learn the graphic view framework's 
drag and drop? Thanks in advance.


Drag and drop is fully supported. Did you try to google for 
"qgraphicsitem drag and drop"?


http://qt-project.org/doc/qt-4.8/qgraphicsitem.html#dragLeaveEvent
http://qt-project.org/doc/qt-4.8/qgraphicsitem.html#dropEvent

Abdel

Re: CMake for Apple?

[Abdelrazak Younes]

On 13/05/2013 14:54, Stephan Witt wrote:

Am 13.05.2013 um 11:20 schrieb Benjamin Piwowarski 
:

When make install from CMake produces an useful result like the auto-tools make 
install
we have a good starting point.  Then one can change the mentioned shell script 
or add its
functionality to the CMake package build.


I don't have a strong preference towards any build system, but the only point 
is that having to take care of updating both each time is cumbersome and 
error-prone. So that's why I am ready to work on it - but only if cmake is 
chosen as the only build system (otherwise, it does not make sense to put so 
much effort in maintaining both working build systems).

Yes, and I have to admit I never had a problem with multiple build systems.
Surely because auto-tools and CMake both are working fine for me most of the 
time.

OK, then maybe this is not worth investing time in it.

Let's wait what others say.


I think it is worth investing time in it. At the meeting everybody 
agreed that we should have one build system in the long run. But to make 
cmake official we need to achieve the following:
1) implement the missing feature of autotools in cmake, especially for 
MAC as I believe that Linux/Unix is complete thanks to the hard work of 
Peter first and then Kornel.

2) Deprecate autotools
3) update the documentation (Readme/Wiki/etc)
4) allow some time for developers to fully switch to cmake
5) remove autotools when we are done, hopefully before 2.1, if not for 2.2.

The one point that still needs discussion is GLOB versus explicit file 
listing. While GLOB is IMO a very nice feature I know and understand 
others dislike it. So I guess we also need to do this in cmake.


So Benjamin, if you are willing to help it will be very good for the 
project.


Final point: This is just a proposal based on the feedback I received 
during the meeting. Other developers might disagree of course and in 
this case we should discuss more :-)


Cheers,
Abdel.

Re: CMake for Apple?

[Abdelrazak Younes]

On Sat, May 11, 2013 at 11:02 PM, Stephan Witt  wrote:

> Am 11.05.2013 um 17:50 schrieb Abdelrazak Younes :
>
> > Hi Stephan,
> >
> > At LyX meeting we are wondering why you are still using autotools for
> Mac packaging. Do you miss anything from CMake that is not implemented yet?
>
> Hi all at the LyX meeting,
>
> I hope you're well and someone is drinking wine too… :)
>

I had some ;-)


>
> Regarding the CMake question - I never tried it for a long time.
>

Ah? I got the impression you were developping using cmake and xcode... But
I see in your other email that this does not work anymore...



> So I cannot answer the question. Isn't the autotools build the official
> one?
>

Up to now yes, except for Windows.

I was trying to advocate yesterday that we should really move to cmake on
all platforms. I guess this is already a lost battle...

Cheers,
Abdel

CMake for Apple?

[Abdelrazak Younes]

Hi Stephan,

At LyX meeting we are wondering why you are still using autotools for Mac
packaging. Do you miss anything from CMake that is not implemented yet?

Abdel.

Re: XML Parsing Library [was Re: XML For LyX]

[Abdelrazak Younes]

On Sat, May 11, 2013 at 12:03 PM, Abdelrazak Younes  wrote:

> On Sat, May 11, 2013 at 8:40 AM, Pavel Sanda  wrote:
>
>> Abdelrazak Younes wrote:
>> > I will discuss that face2face during the meeting.
>>
>> You should bring mirror then, no one else in this thread is in Milano.
>> Anyway it's too late, Richard already barricaded in underground garage of
>> his
>> house and won't show until 378 patches implementing xml is done as I infer
>> from the last testament.
>>
>
> I just discussed with Lars. He agrees that using Qt is a good option...
> what a shock ! :-)
> Vincent and JMarc don't care what we use.
>
> I am talking about QXmlStreamReader and (as a second step)
> QXmlStreamWriter. Our lexer class can just use QXmlStreamReader internally,
> we don't have to spread the use of this call all other the place.
>
> So Richard, let's use a new "feature" repo for that. This is agreed with
> Lars, Vincent and JMarc. Then we would create an "xml" branch in that repo.
>
> Lars and Vincent are setting this up right now :-)
>

So now it is set up, look (and check) at the documentation here:

http://wiki.lyx.org/Devel/LyXGit

I have erased all old branches because we want only feature branches based
on "master".

I just created "xml" branch in there.

Richard, I guess you are still sleeping so I hope you agree with all that.
My goal is that we  collaborate on the XML support using this shared branch
and repo.

Abdel

Re: XML Library Question Answered?

[Abdelrazak Younes]

Hum I just saw this thread...
So we all agree, that's good.

Abdel.


On Fri, May 10, 2013 at 10:09 PM, Nico Williams wrote:

> On Fri, May 10, 2013 at 12:45 PM, Richard Heck  wrote:
> > The only significant worry here concerns stability: Could a Qt update
> break
> > us? We already depend heavily on Qt, so this is not as large a concern as
> > with depending upon other external libraries. And my sense is that these
> > classes are likely to be pretty stable.
>
> QXmlStreamReader looks perfect for parsing LyX XML.  QXmlStreamWriter
> looks perfect for writing it.
>
> I seriously doubt these will be unstable.  Note that writing [valid]
> XML is much easier than reading it, so you could write your own stream
> writer.  Reading actually isn't that hard either -- it helps to not
> support external entities (and, indeed, QXmlStreamReader doesn't).
> But really, XML itself is stable, and these libraries look
> well-matched up to XML (as one would expect), so I see no reason for
> there to be backwards incompatible API/ABI/semantic changes to them.
> Removal, OTOH, is much harder to foresee, but in that case you can
> just write your own streamers.
>
> Nico
> --
>

Re: XML Parsing Library [was Re: XML For LyX]

[Abdelrazak Younes]

On Sat, May 11, 2013 at 11:11 AM, Andrew Parsloe wrote:

>
>>  It is absolutely none of my business, but I do enjoy my daily 'fix'
> eavesdropping on developer messages.
>

The live show is even more entertaining :-)

Alessandro, do you like it?

Abdel.

Re: XML Parsing Library [was Re: XML For LyX]

[Abdelrazak Younes]

On Sat, May 11, 2013 at 8:40 AM, Pavel Sanda  wrote:

> Abdelrazak Younes wrote:
> > I will discuss that face2face during the meeting.
>
> You should bring mirror then, no one else in this thread is in Milano.
> Anyway it's too late, Richard already barricaded in underground garage of
> his
> house and won't show until 378 patches implementing xml is done as I infer
> from the last testament.
>

I just discussed with Lars. He agrees that using Qt is a good option...
what a shock ! :-)
Vincent and JMarc don't care what we use.

I am talking about QXmlStreamReader and (as a second step)
QXmlStreamWriter. Our lexer class can just use QXmlStreamReader internally,
we don't have to spread the use of this call all other the place.

So Richard, let's use a new "feature" repo for that. This is agreed with
Lars, Vincent and JMarc. Then we would create an "xml" branch in that repo.

Lars and Vincent are setting this up right now :-)

Abdel.

Re: XML Parsing Library [was Re: XML For LyX]

[Abdelrazak Younes]

Guys

Qt has a nice xml reader
Also one with a nice stream like interface that would fit nicely in ours
parser. And it quite fast too.

I will discuss that face2face during the meeting.

Abdel
On May 9, 2013 11:26 PM, "Richard Heck"  wrote:

> On 05/09/2013 02:25 PM, Pavel Sanda wrote:
>
>> Richard Heck wrote:
>>
>>> On Linux, of course, it is different. One would just expect this library
>>> already to be installed. But things do not work that way on the other
>>> OSs.
>>>
>> I belive we should actually _include_ some leightweight library in our
>> sources so it is fixed and we do not rely in any versioning problem or
>> avalability on various architectures.
>>
>
> I had the same thought.
>
> Richard
>
>

Re: GSOC Toolbar Customization Dialog

[Abdelrazak Younes]

Hi Mihai,

Please always keep the devel list in CC as I might not be available.
I think you can re-read the config file if you reset the global preferences.

Abdel.



On Mon, Apr 29, 2013 at 9:07 PM, Mihai Varga  wrote:

> Hello Abdel,
> My name is Mihai Varga, I have sent a couple of weeks ago a mail on the
> lyx-devel mailing list asking about the Toolbar Customization Dialog
> project. After which, you replied with some links pointing to the
> repositories, i am sorry for such a late response, i have been very busy
> with mid term exams, but i'm done now, so this is what i've done so far:
> -I have added that patch to the current master branch, i had to make a few
> changes in the /src/Buffer files, the patch requested some functions that
> weren't defined, but unknowing what actually their purposes are, i haven't
> completed them, just defined them for the program to run.
> -As for the toolbar customization, i have added a button that removes the
> first button from the first toolbar (for test purpose), but in order for
> the change to take effect i must restart Lyx, is there a way i could tell
> Lyx to read again the stdtoolbar.inc (the config) file? i couldn't find it
> on google. Or if there isn't possible i should try to approach it another
> way, but i believe this would be better because people could still modify
> it from the file.
>

Re: GSoC - Toolbar Customization Dialog

[Abdelrazak Younes]

On 13/04/2013 13:23, Mihai Varga wrote:
Hello, my name is Mihai, i'm a first year student at 
the Polytechnic University of Bucharest, and i am interested in the 
Toolbar Customization Dialog project. Could you please give me a 
starting idea or let me know if there are any issues related to this 
matter that i can solve. I have acquired some experience with C++ in 
college and Qt by contributing to an open-source project. I would very 
much appreciate it if you could give me some tips and tricks on how to 
start writing my application.


Hi Mihai,

I don't have much time to support this development currently so let me 
quote what I just wrote to Manan a minute ago:


A while ago I started this branch:

https://gitorious.org/lyx/lyx/commits/younes/toolbar-settings

There is only one commit:

https://gitorious.org/lyx/lyx/commit/09d4c8e9fe139951209110c789bd6ca563942013

So maybe as a first step you can frontport this commit to current 
master. If you are motivated, you can first create a new branch for your 
development from latest master and then apply this patch. Even if the 
patch is quite old I don't think much has changed since that time.


There is a think plenty of work for you both so maybe you can work 
together by sharing a lyx clone or a branch?


Good luck.
Abdel.

Re: GSOC 2013

[Abdelrazak Younes]

Hi Manan,

A while ago I started this branch:

https://gitorious.org/lyx/lyx/commits/younes/toolbar-settings

There is only one commit:

https://gitorious.org/lyx/lyx/commit/09d4c8e9fe139951209110c789bd6ca563942013

So maybe as a first step you can frontport this commit to current 
master. If you are motivated, you can first create a new branch for your 
development from latest master and then apply this patch. Even if the 
patch is quite old I don't think much has changed since that time.


Good luck.
Abdel.


On 14/04/2013 09:14, Manan Dang wrote:

Thanks for your reply,

I have started working on Qt4 for the current project I mentioned
I have tried to make a simple toolbar using Qt itself.
This is the one I have made [1].
The source code is also attached with which I made this [2].
I have also looked for some files for tool bar int the project "Lyx" 
and found some files related to tool bar :


lyx/ src/ frontends/ qt4/ toolbars.cpp
lyx/ src/ GuiToolbar.cpp
lyx/ src/ moc_GuiToolbar.cpp
lyx/ src/ Toolbars.cpp

I have gone through the files and got the overview of "Toolbars.cpp" 
and "GuiToolbar.cpp" about what is going in these files and how it is 
working.


I have also seen in Lyx that all the tools in tool bar are display as 
one. In my project I need the tool bar to be customized by the user 
through GUI only. So I need to know where to proceed now for 
customizing tool bar through GUI.


As far as I think i need to change the "GuiToolbar.cpp" so that user 
can modify the tool bar without going through  and editing the 
configure file manually.


It will be very helpful for me if i get some guidance about the 
project and got to know where shall I proceed now.


[1] http://snag.gy/Bab9Z.jpg
[2] http://pastebin.com/vmW7xt8u "simplemenu.h"
http://pastebin.com/5YadchGJ "gui.cpp
http://pastebin.com/Sq4KPc5Y "main.cpp"




On Sun, Apr 14, 2013 at 11:53 AM, Liviu Andronic 
mailto:landronim...@gmail.com>> wrote:


Dear Manan,
Welcome to LyX.


On Thu, Apr 11, 2013 at 3:13 PM, Abdelrazak Younes mailto:you...@lyx.org>> wrote:
>> Hi  Abdelrazak Younes,
>> I am a junior year undergraduate student from Delhi Technological
>> University pursuing Computer Science Engineering.
>>
>> I went through the project ideas for GSOC [1] and found an
interesting
>> project to work on
>>
>> PROJECT: Toolbar Customization Dialog
>>
>> I have cloned the source code of "Lyx" and also installed Qt4 and
>> Qt4-devel packages. I have also built the Lyx code and now I am
interested
>> to work on this project and want to apply for GSOC 2013. How
may I proceed.
>
To apply to GSoC 2013 for a project related to LyX please follow the
application procedure outlined here:
http://www.google-melange.com/gsoc/org/google/gsoc2013/lyx . Feel free
to ask on lyx-devel specific questions related to the project you'd
like to be working on.


>> Also are there any junior jobs that I can do to get more
comfortable with
>> the code base.
>
If you're looking for easy targets to get familiar with the codebase
then search for 'easyfix' on the bug tracker:

http://www.lyx.org/trac/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~easyfix&summary=~&description=~&reporter=~&col=id&col=summary&col=reporter&col=status&col=type&col=severity&col=keywords&desc=1&order=id

<http://www.lyx.org/trac/query?status=accepted&status=assigned&status=new&status=reopened&keywords=%7Eeasyfix&summary=%7E&description=%7E&reporter=%7E&col=id&col=summary&col=reporter&col=status&col=type&col=severity&col=keywords&desc=1&order=id>
.

Regards,
Liviu




--
Regards
Manan Dang
COE,3rd Year
-Internship Coordinator
-Joint Secretary,CSI-DTU
DELHI TECHNOLOGICAL UNIVERSITY
(formerly Delhi College Of Engineering)
Mob: +919013619399

Re: GSOC 2013

[Abdelrazak Younes]

Hi Manan,

Let me forward your request to the development list.

Abdel.

--
> *De: *"Manan Dang" 
> *Envoyé: *Mercredi 10 Avril 2013 21:38:55
> *Objet: *GSOC 2013
>
> Hi  Abdelrazak Younes,
> I am a junior year undergraduate student from Delhi Technological
> University pursuing Computer Science Engineering.
>
> I went through the project ideas for GSOC [1] and found
> an interesting project to work on
>
> PROJECT: Toolbar Customization Dialog
>
> I have cloned the source code of "Lyx" and also installed Qt4 and
> Qt4-devel packages. I have also built the Lyx code and now I
> am interested to work on this project and want to apply for GSOC 2013. How
> may I proceed. Also are there any junior jobs that I can do to get more
> comfortable with the code base.
>
> [1]: http://wiki.lyx.org/Devel/SummerOfCode2013Ideas
>
> Thank You
> --
> Regards
> Manan Dang
> COE,3rd Year
> -Internship Coordinator
> -Joint Secretary,CSI-DTU
> DELHI TECHNOLOGICAL UNIVERSITY
> (formerly Delhi College Of Engineering)
> Mob: +919013619399
>
>
>

Re: Assertion when exporting on command line with missing user directory

[Abdelrazak Younes]

On 06/04/2013 20:04, Scott Kostyshak wrote:

On Sat, Apr 6, 2013 at 11:28 AM, Richard Heck  wrote:

On 04/05/2013 11:31 PM, Scott Kostyshak wrote:

Should LyX exit more gracefully here?

$ lyx -e pdf2 Intro.lyx
Missing user LyX directory

You have specified a non-existent user LyX directory,
/home/scott/lyxbuilds/master/user-dir.
It is needed to keep your own configuration.
Assuming answer is &Exit LyX


Note that this only happens in devel mode. In release mode, we continue and
exit in the usual way. So I think this one is fine, though maybe we don't
really need to assert in this case. You might could check some other flag?

Makes sense. I'll leave it alone.


There's actually a general need to look through all the LASSERT statements
from this point of view. In many cases, we just continue in release mode if
the assertion fails, when that is clearly going to lead to a crash, and we
could take some other remedial action. Often, just returning out of that
function will do.

Good point. I never thought about this. I wonder if in other cases
something might be so wrong that LyX should safely quit and ask for
the user to file a bug report. I'm guessing we don't have a macro for
that because in each case "safely quit" might mean something
different.


Side note from an old timer:

André put in in place this LASSERT macro with fallback capability. He 
did a global search&replace and the default fallback is to do nothing. 
The goal was to eventually go through all those assertion and provide a 
sensible fallback which is different in each case. So to complement what 
Richard said. LyX would improve his general stability if this work is done.


Abdel.
*

Re: Horrible Assertion Failures: What To Do?

[Abdelrazak Younes]

On 06/04/2013 19:01, Richard Heck wrote:


Consider this function:

TextMetrics & BufferView::textMetrics(Text const * t)
{
LASSERT(t, /**/);
TextMetricsCache::iterator tmc_it  = d->text_metrics_.find(t);
if (tmc_it == d->text_metrics_.end()) {
tmc_it = d->text_metrics_.insert(
make_pair(t, TextMetrics(this, const_cast*>(t.first;

}
return tmc_it->second;
}

Probably, the only way we get an assertion here is (a) someone did 
something very stupid or (b) we have some kind of memory corruption. 
It seems to me that, in this kind of case, perhaps the best thing for 
us to do is:

LASSERT(t, emergencyCleanup());
We will end up there anyway, so perhaps it is better just to do it 
before things get worse.


That is my thinking, anyway.


Looks sensible.

Abdel.

Re: Anchor Crashes

[Abdelrazak Younes]

On 06/04/2013 20:36, Richard Heck wrote:


There have been several bugs recently (such as #8001) that involve 
failures somewhere to reset the anchor. Something like the attached 
would allow us to recover gracefully in release mode, while still 
asserting in development mode. Does this seems sensible?


Yes.


Does the way I've gotten around const-ness make sense?


Yes.

But you should not remove curly brackets around two lines 'if' even if 
the first line is a comment.


Abdel.

Re: [LyX master] Add a WIN32 equivalent for gettimeofday

[Abdelrazak Younes]

On 25/03/2013 13:45, Jean-Marc Lasgouttes wrote:

Le 25/03/2013 12:07, Vincent van Ravesteijn a écrit :

Yes, I think we should. On Windows, it takes around 200-250usec to get a
translated message, while on Linux you estimated it as 5usec. So, the
issue might pop up in other situations as well, even though there are no
problems on Linux.


OK.


I remember spending maybe 2 days chasing this slowness under Windows and 
you want to get rid of my cache with a snap of the finger?





On a side note, approximately 160-180usec is spent in setting and
unsetting the environment variables. I'd expect that this would not be
needed to do for each translation request. Removing those calls from the
Messages::get function would reduce the time to 40-50usec for each
call. I don't know right now why it is still much slower than the 5usec
on Linux.


Interesting. Now I know why gettext is slow with windows. It is 
environment setting that takes all the time.


This is because of the horrible API of gettext. We can need several 
different languages at the same time, and we cannot pass that as a 
parameter. Moreover, if we leave these environment variables as set, 
they will influence the behavior of the external processes that we run.


I am more and more tempted at use some C++ .mo file reader like
this
  https://github.com/laurent22/simple-gettext

This library amounts to less that 1000 lines of code AFAICS. We can 
afford to import it in our code and customize it to our needs. I just 
have to find a clear statement about license.


Besides reading mo files, what does the horrible gettext code buys us?

* auto detection of the OS language: Qt can do that.
* encoding conversion: we already have some iconv stuff of our own, and
  we could enforce using UTF8 in our po files if it is not yet the case.
* special handling for plural forms, context (we do our own),

All in all, I think life would be easier.


Abdel, go out of this body!

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

On 18/03/2013 10:21, Jean-Marc Lasgouttes wrote:

Le 17/03/2013 15:25, Abdelrazak Younes a écrit :


And off course: stabilize devel for 2.1 release.


Another plan would be to relelase 2.1 before the meeting. Is this 
possible? I am not sur e that we have so many regressions wrt 2.0 in 
current trunk.


That would be best.



Anyway, I think flat directory structure is something that should be 
done just before release, unless git is better that I think at 
following renames.


Git is close to perfect for that.

Abdel.

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

On 14/03/2013 10:00, Jean-Marc Lasgouttes wrote:

Le 14/03/2013 01:04, Alessandro Di Federico a écrit :

On Sun, 2013-02-24 at 12:36 +0100, Vincent van Ravesteijn wrote:

I did too.. sort of.


It'd be nice to expand a bit the "what are we going to discuss" section.


The most interesting is in general "what are we going to code". This 
is not decided in advance in general, although people usually come 
with a wish list. For example, a big point for me this year is 
word-level text metrics, since our current code causes many problems. 
And maybe getting rid of most of our bidi code if we are lucky and qt 
can do it all for us. But I am definitely not competent enough on 
these subjects, which is why a LDM is the good place to do it.


The best solution is of course to entice somebody more competent (yes, 
Abdel I am looking at you!) to do it :)


Not sure I still have the competence... but we can try :-)

Other ideas:
* flat directory structure.
* more core /  gui separation
* get rid of the complicated graphics stuff
* replace the pixmap/image backend with QGraphicsView.
* Qt5 compilation and testing
* libgit2 integration

And off course: stabilize devel for 2.1 release.

Abdel.

Re: editing math in lyx

[Abdelrazak Younes]

On 14/03/2013 15:14, Alex Vergara Gil wrote:


Isn´t there a better way to do this inside LyX?
I think this is a good feature request for developers, is not that hard
to put a button inside the math environment that switches between TeX
and rendered math mode, and when exited you see only rendered. I don´t
know if I am making myself clear, so I will explain this a little more.

1 Enter in math mode and add some equation/whatever.
2 Now I want to add some TeX code directly or edit what I have
introduced, so I press the (requested) switch button and I could see all
in TeX code.
3 I edit the TeX code  and when finished press the switch button again
(or just leave math mode), the result should be the new rendered
equation/whatever I have edited.

This feature would be great for middle to power users, off course one
should only expect math code inside the math mode so it would be nice to
clarify this in the manual if it is actually included.

I know I can do this in a ERT environment but then I need to copy to
math but that´s not an optimal approach.


This sounds like a not very hard feature to implement, maybe without 
touching C++ even. So why don't you implement this yourself and propose 
a patch? There are not many active developers these days so LyX users 
must participate to the development if they want to see LyX evolve.


Abdel.

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

On 21/01/2013 02:23, Scott Kostyshak wrote:

On Sun, Jan 20, 2013 at 7:49 PM, Uwe Stöhr  wrote:

Am 21.01.2013 01:43, schrieb Scott Kostyshak:



I have been following with jealousy.


Just come over.

Hopefully next time.

Scott


Why that? If this is a money problem Lars said that there are some money 
available. It seems that you are one of the main developer these day so 
your input will be very important.  So don't be shy.


Abdel.

Re: PATCH to make Qt5 (and Qt4) compilable [Re: #8250: OS X with retina display]

[Abdelrazak Younes]

On 03/02/2013 21:27, Stephan Witt wrote:

Am 03.02.2013 um 20:40 schrieb Abdelrazak Younes :


On 02/02/2013 23:07, Stephan Witt wrote:

Am 02.02.2013 um 09:10 schrieb Abdelrazak Younes :


On 31/01/2013 21:44, Stephan Witt wrote:

Am 28.01.2013 um 10:02 schrieb LyX Ticket Tracker :


#8250: OS X with retina display
-+-
Changes (by spitz):

Does it make a difference if "Use pixmap cache" in Tools > Preferences >
Look & Feel > Screen Fonts is unchecked? (Note that this might decrease
performance). It would surprise me if Stephan wouldn't have tested this
already, but let's make sure.

Generally, this bug report is relevant:
https://bugreports.qt-project.org/browse/QTBUG-23870

Seems that some general support for HIGH_DPI is planned for Qt 5.0. In any
case, the report has some instructive background information.

Thank you, Jürgen, for the pointer to the Qt bug report.

I studied it and came to the conclusion to give LyX+Qt5 a try. The attached 
patch is a result of this effort.

Instead of push it to git I want to present it here to get some feedback. If 
the changes are ok I want to commit the patch.

Looks good after a quick parsing of it. It would be better if we minimize the 
number of #ifdef... maybe via some small inline wrappers?

Thank you for having a look at it.

Most of the #ifdef's are needed for Qt's change of QAbstractItemView 
setResizeMode to setSectionResizeMode.

I can place a wrapper in qt_helpers.h/qt_helpers.cpp like in the attached 
patch. But I failed to make it inline.
Would you prefer this anyway?

Yes, looks better, thanks.

Another comment... I see this:

+++ b/src/support/FileName.cpp
@@ -746,7 +746,11 @@ docstring FileName::fileContents(string const & encoding) 
const
 if (encoding.empty() || encoding == "UTF-8")
 s = QString::fromUtf8(contents.data());
 else if (encoding == "ascii")
+#if (QT_VERSION < 0x05)
 s = QString::fromAscii(contents.data());
+#else
+s = QString::fromLatin1(contents.data());
+#endif

This doesn't look correct. Latin1 is not ascii. I can see that the Qt5 doc says 
that QString::fromAscii() and toAscii are deprecated because their give wrong 
results, that is latin1, not ASCII. Still, this is not clean.

Yes, this is one thing I don't understand either.
1) The doc say it's deprecated but I got:
src/support/FileName.cpp: In member function ‘lyx::docstring 
lyx::support::FileName::fileContents(const std::string&) const’:
src/support/FileName.cpp:750: error: ‘fromAscii’ is not a member of ‘QString’


Maybe your version of Qt was compiled without support for deprecated stuff.


2) Why isn't it possible to provide a correct fromAscii implementation then?


Maybe because it involves some content checking... Basically anything 
greater than 7 bit ASCII must be discarded. But I am astonished that Qt 
doesn't provide this kind of sanity check for ASCII. We could do it by 
ourselves quite easily or maybe use some iconv function.



So, I had no good idea for Qt5 for a fromAscii() implementation. What do you 
propose?


I read from Qt4 doc that fromAscii() is the same as as fromLatin1() if 
no codec is installed. In Qt5 they just removed the ambiguity of 8 bits 
ASCII by just choosing Latin1. So I would just remove the #ifdef and 
just use fromLatin1() also fro Qt4. I would also add a FIXME explaining 
the issue of course.





Sorry, I didn't want to commit the whole thing. It just happens while I tried 
to build a master branch with non-controversial stuff and to commit that. 
Igittigit…


No PB.

Cheers,
Abdel.

Re: PATCH to make Qt5 (and Qt4) compilable [Re: #8250: OS X with retina display]

[Abdelrazak Younes]

On 02/02/2013 23:07, Stephan Witt wrote:

Am 02.02.2013 um 09:10 schrieb Abdelrazak Younes :


On 31/01/2013 21:44, Stephan Witt wrote:

Am 28.01.2013 um 10:02 schrieb LyX Ticket Tracker :


#8250: OS X with retina display
-+-
Changes (by spitz):

Does it make a difference if "Use pixmap cache" in Tools > Preferences >
Look & Feel > Screen Fonts is unchecked? (Note that this might decrease
performance). It would surprise me if Stephan wouldn't have tested this
already, but let's make sure.

Generally, this bug report is relevant:
https://bugreports.qt-project.org/browse/QTBUG-23870

Seems that some general support for HIGH_DPI is planned for Qt 5.0. In any
case, the report has some instructive background information.

Thank you, Jürgen, for the pointer to the Qt bug report.

I studied it and came to the conclusion to give LyX+Qt5 a try. The attached 
patch is a result of this effort.

Instead of push it to git I want to present it here to get some feedback. If 
the changes are ok I want to commit the patch.

Looks good after a quick parsing of it. It would be better if we minimize the 
number of #ifdef... maybe via some small inline wrappers?

Thank you for having a look at it.

Most of the #ifdef's are needed for Qt's change of QAbstractItemView 
setResizeMode to setSectionResizeMode.

I can place a wrapper in qt_helpers.h/qt_helpers.cpp like in the attached 
patch. But I failed to make it inline.
Would you prefer this anyway?


Yes, looks better, thanks.

Another comment... I see this:

+++ b/src/support/FileName.cpp
@@ -746,7 +746,11 @@ docstring FileName::fileContents(string const & 
encoding) const

 if (encoding.empty() || encoding == "UTF-8")
 s = QString::fromUtf8(contents.data());
 else if (encoding == "ascii")
+#if (QT_VERSION < 0x05)
 s = QString::fromAscii(contents.data());
+#else
+s = QString::fromLatin1(contents.data());
+#endif

This doesn't look correct. Latin1 is not ascii. I can see that the Qt5 
doc says that QString::fromAscii() and toAscii are deprecated because 
their give wrong results, that is latin1, not ASCII. Still, this is not 
clean.


Abdel.

Re: PATCH to make Qt5 (and Qt4) compilable [Re: #8250: OS X with retina display]

[Abdelrazak Younes]

On 31/01/2013 21:44, Stephan Witt wrote:

Am 28.01.2013 um 10:02 schrieb LyX Ticket Tracker :


#8250: OS X with retina display
-+-
Changes (by spitz):

Does it make a difference if "Use pixmap cache" in Tools > Preferences >
Look & Feel > Screen Fonts is unchecked? (Note that this might decrease
performance). It would surprise me if Stephan wouldn't have tested this
already, but let's make sure.

Generally, this bug report is relevant:
https://bugreports.qt-project.org/browse/QTBUG-23870

Seems that some general support for HIGH_DPI is planned for Qt 5.0. In any
case, the report has some instructive background information.


Thank you, Jürgen, for the pointer to the Qt bug report.

I studied it and came to the conclusion to give LyX+Qt5 a try. The attached 
patch is a result of this effort.

Instead of push it to git I want to present it here to get some feedback. If 
the changes are ok I want to commit the patch.


Looks good after a quick parsing of it. It would be better if we 
minimize the number of #ifdef... maybe via some small inline wrappers?





Unfortunately it doesn't solve the problem with high resolution displays. 
There's more work to do...

The pixmap cache isn't enabled per default on Mac OS X. We have a problem with 
QPainter's text drawing mechanism.


I think you can remove the pixmap cache for 2.1, I don't think it is used.

Abdel.

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

On Thu, Dec 27, 2012 at 10:04 PM, Jean-Marc Lasgouttes
wrote:

> Le 27/12/12 20:44, Alessandro Di Federico a écrit :
>
>  On Thu, 2012-12-27 at 16:26 +0100, Jean-Marc Lasgouttes wrote:
>>
> I am not sure we need a good hotel. Some mattresses to sleep on may be
>>> enough. The event is very very informal: programming, discussing,
>>> drinking beer and eating an occasional sandwich until 2AM.
>>>
>>
>> Yeah, that would be cool, but the university is closed at night.
>>
>
> And is it possible to find a place with internet connection which is open
> at night? That is probably an important constraint.
>

On the other hand we could relax a bit the rules and say that the meeting
is off at 21p.m. so that we can have some fun outside...

Abdel.

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

On Thu, Dec 27, 2012 at 4:54 PM, Vincent van Ravesteijn  wrote:

> Op 27-12-2012 16:26, Jean-Marc Lasgouttes schreef
>
>>
>> In France, May 9 is a non-working day (Ascension day), is it the same in
>> Italy (we also have May 8 for the end of WW2, but I somehow doubt it is a
>> national day in Italy...).
>>
>
> I'll be off at May 9 as well.


Same here in Switzerland.



>
>>  Please let me know how many would join!
>>>
>>
>> I will.
>>
> I will too.
>

I have to enter negociation with my wife but I'll try to come.

Abdel.

Re: [LyX master] Merge branch 'master' of git.lyx.org:lyx

[Abdelrazak Younes]

On Tue, Jan 8, 2013 at 9:52 AM, Jean-Marc Lasgouttes wrote:

>
> Goddwill and willingness to understand what you know and what you don't
> are good enough (for all of us).
>


Please, don't bring religion to this list!

Abdel

Re: Where to use qt4 (Re: Export-to fails for xhtml)

[Abdelrazak Younes]

On Tue, Dec 11, 2012 at 3:57 PM, Abdelrazak Younes  wrote:

>
> A while ago, I proposed a flatter directory structure, I will look for it.
>

Here is it:

src/lyx/ : basically one C++ file with main() using the other libraries
below or not

src/boost/ : to be removed later when we get rid of boost.

src/intl/

src/core/ :
  everything that is now in src/. Some of that may go in new src/export/
and src/import/ directories.

src/gui/ :
 everything that is now in
 src/frontents/
 src/frontents/qt4
 src/frontents/qt4/ui
 src/graphics/ (mostly)

src/support/ : same as now
src/insets/ : same as now plus a bit of what is now in src/graphics
src/mathed/ : same as now
src/tex2lyx/ : same as now. Most of that may go in new src/import/ directory
.
src/client/ : same as now

This way we would have one directory per program or library.

Abdel.

Re: Where to use qt4 (Re: Export-to fails for xhtml)

[Abdelrazak Younes]

Ah... a flameware just in time before Christmas! :-P

On Tue, Dec 11, 2012 at 1:09 PM, Pavel Sanda  wrote:

> Tommaso Cucinotta wrote:
> > Yes, everything compiles fine. Also ColorCache.h was not giving any
> trouble, till I included it in graphics/PreviewLoader.cpp, because then gcc
> > complained it cannot find QColor nor QPalette (and I had to add the
> QtGui/).
>
> Yes I understand the issue now. Qt4 creeping out of qt4/ directory.
> I don't have strong opinion since we already crossed the line in server
> and compare feature. But other may have some comments as well, it's not
> just
> technical issue (shall we get rid of frontend/qt4 structure?)
>


A while ago, I proposed a flatter directory structure, I will look for it.
the graphics namespace is really an artefact of the past, it should be
completely merged in the frontend code.

And of course we should get rid of frontend/* (not qt4) and use signal/slot
connection for communication with the core (src/).

Abdel



> Pavel
>

Re: New layout argument work and Beamer

[Abdelrazak Younes]

Thanks for the detailed explanation Jurgen, I look forward to using it :-)

This new layout infrastructure actually would justify a new new major
release.

Abdel.



On Tue, Nov 27, 2012 at 1:51 PM, Jürgen Spitzmüller  wrote:

> Abdelrazak Younes wrote:
> > Hi Jurgen,
> >
> > I am not sure I understand your recent work but can this be used to
> improve
> > the beamer layouts?
>
> Yes, and actually this was one of my main motivations.
>
> I have already a reworked beamer layout with most overlay insets
> implemented
> (as in \section{text} or \only<2->{text}). It's attached for
> information.
>
> However, this requires a file format change, since the inset order changes.
> Richard reported that he intends to make lyx2lyx convert our known layout
> format to the correct argument number instead of delegating the
> calculation to
> the inset. I'll wait for that, since this will make the beamer
> transformation
> much easier.
>
> > Recently I wanted to use program listing and I had to use a module I
> found
> > in the wiki that adds the [fragile] keywords to the bearmer frame. So my
> > question is can we use your work to tag a frame as fragile?
>
> Not yet, but I plan to implement a proper frame environment and get rid of
> the
> lyxframe, lyxframeend (and all other lyx-specific hacks) in the layout.
>
> My rough plan is to implement a new layout style (say Frame_Environment),
> that
> will
>
> * directly use the paragraph content as a mandatory argument (as in
> \begin{frame}{par content} and \begin{block}{par content})
>
> * by default nest consecutive paragraphs (with a nested standard paragraph
> as
> default if you hit Enter in a Frame paragraph; two consecutive Enters get
> you
> out of the frame, same as in list nestings)
>
> * separate consecutive frame paragraphs without the need of a "separator".
>
> Effectively, this should result in a hack-less LaTeX code without any
> limitations wrt beamer use, but also without any drawbacks in LyX usage
> (one
> of the disadvantages of the proposed module).
>
> Jürgen
>
> > Thanks,
> > Abdel.
>

New layout argument work and Beamer

[Abdelrazak Younes]

Hi Jurgen,

I am not sure I understand your recent work but can this be used to improve
the beamer layouts?

Recently I wanted to use program listing and I had to use a module I found
in the wiki that adds the [fragile] keywords to the bearmer frame. So my
question is can we use your work to tag a frame as fragile?

Thanks,
Abdel.

Re: LyX developer meeting or not ?

[Abdelrazak Younes]

I would come.

Abdel

On Wed, Nov 21, 2012 at 3:05 PM, Jean-Marc Lasgouttes
 wrote:
> Hi there,
>
> A month ago, when Alessandro Di Federico mentioned that he was doing a LyX
> user conference on LyX in April at the Politecnico
> di Milano, I foolishly answered that it would be great to do a developer
> meeting at the same time. One reason is that I think we sorely need one, and
> the other that meeting users is more fun (and I do not know Milano yet).
>
> The problem is, that nobody answered and the poor Alessandro is left
> wondering whether he should do something or not. So I want to ask for
> explicit answers from you, fellow developers: is there any interest for
> doing that? Do we prefer to do a meeting in some other place and some other
> moment (or not at all)?
>
> Please react, so that we can feel whether it is worth pursuing this.
>
> JMarc

Re: Leftovers

[Abdelrazak Younes]

On 04/11/2012 01:48, Pavel Sanda wrote:

Pavel Sanda wrote:

commit 0a9735c5f7bbbaa24ac2e3e4fa745c6dfbc95a18
Author: Pavel Sanda 
Date:   Sun Nov 4 01:18:16 2012 +0100

 LyX 2.1 will support only Qt>=4.5.
 
 (http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg175737.html)
 
 Now start with simple cases.

There are few things left, I'm not sure what was the original issue, but you 
may remember:

1) things related to threading/autosave:
src/Buffer.cpp- /// This function is deprecated as the frontend needs 
to take care
src/Buffer.cpp- /// of cloning the buffer and autosaving it in another 
thread. It
src/Buffer.cpp: /// is still here to allow (QT_VERSION < 0x040400).
src/Buffer.cpp- AutoSaveBuffer autosave(*this, fname);
src/Buffer.cpp- autosave.start();
src/Buffer.cpp- return true;


This is in case threaded export is not enabled. At first there was a 
macro to conditionally enable this feature. But it seems this macro is 
no more and you can thus safely erase this code.



src/frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
src/frontends/qt4/GuiView.cpp-  GuiViewPrivate::busyBuffers.insert(buffer);
src/frontends/qt4/GuiView.cpp-  QFuture f = 
QtConcurrent::run(GuiViewPrivate::autosaveAndDestroy,
src/frontends/qt4/GuiView.cpp-  buffer, buffer->cloneBufferOnly());
src/frontends/qt4/GuiView.cpp-  d.autosave_watcher_.setFuture(f);
src/frontends/qt4/GuiView.cpp-#else
src/frontends/qt4/GuiView.cpp-buffer->autoSave();
src/frontends/qt4/GuiView.cpp-#endif


Ditto.

Abdel

Re: boost

[Abdelrazak Younes]

On 26/10/2012 23:42, Lars Gullik Bjønnes wrote:

Pavel Sanda  writes:

| | BTW after some decade we still include boost in our tarballs and maintain
| its updates. What was the original reason and is it still needed?

My preferences are as follows:

0. Standard C++
1. Something with the same apis/behaviour as standard C++
2. Use something that is destined for standardization.
3. third party libraries.

In a lot of cases 1 & 2 is solved by boost, when the stdlib/toolchain at
hand does not support it directly.


My preferences: always favour cleaner, easier to read code.

I agree that C++11 is nice for a lot of things but please don't 
re-inject more boost in our source code. We took a lot of time to 
understand and simplify some code using advanced template techniques, I 
wouldn't want us to go back there. Some people might not agree but our 
conversion to use Qt instead of boost simplified and robustified the 
code base a lot. Qt is there to stay in our code base so pretty please, 
let's just use it when it make sense.


Abdel.