Le 10/05/2011 20:02, Julien Rioux a écrit :
> On 10/05/2011 9:39 AM, Michel Lavaud wrote:
>> Le 10/05/2011 13:46, Richard Heck a écrit :
>>
I would find it an improvement if, in the "Plan" window, the sequence
chapter / section/ etc. currently opened remained opened when opening
anot
Am Dienstag, 10. Mai 2011 schrieb Peter Kümmel:
> On 10.05.2011 10:50, Jean-Marc Lasgouttes wrote:
> > Le 07/05/11 13:32, Peter Kümmel a écrit :
> >> I think we couldn't do much here. cmake tries to re-use the path to the
> >> sources which
> >> contain "../.." and replaces them by "__/__".
> >>
>
On 10.05.2011 10:50, Jean-Marc Lasgouttes wrote:
Le 07/05/11 13:32, Peter Kümmel a écrit :
I think we couldn't do much here. cmake tries to re-use the path to the
sources which
contain "../.." and replaces them by "__/__".
But it's internal to cmake. Why is it a problem to you?
I find this ug
On 10/05/2011 9:39 AM, Michel Lavaud wrote:
Le 10/05/2011 13:46, Richard Heck a écrit :
I would find it an improvement if, in the "Plan" window, the sequence
chapter / section/ etc. currently opened remained opened when opening
another chapter or section, etc.
Isn't this what the "Keep" butto
Le 10/05/2011 13:46, Richard Heck a écrit :
>> I would find it an improvement if, in the "Plan" window, the sequence
>> chapter / section/ etc. currently opened remained opened when opening
>> another chapter or section, etc.
>>
> Isn't this what the "Keep" button does?
>
Sorry, my question was
On 05/10/2011 03:56 AM, Michel Lavaud wrote:
> On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
>> Hi everyone,
>>
>> As a typical start of a new release cycle I want to poll
>> - what features are a must in the next release;
>> - what work do you think you will be doing;
>> - what do you hope to
Le 07/05/11 13:32, Peter Kümmel a écrit :
I think we couldn't do much here. cmake tries to re-use the path to the
sources which
contain "../.." and replaces them by "__/__".
But it's internal to cmake. Why is it a problem to you?
I find this ugly, but I may be able to live with it after all.
On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
> Hi everyone,
>
> As a typical start of a new release cycle I want to poll
> - what features are a must in the next release;
> - what work do you think you will be doing;
> - what do you hope to see somebody else to do (please keep it
> realistic)
Am 09.05.2011 um 23:02 schrieb Peter Kümmel:
> On 09.05.2011 22:56, Stephan Witt wrote:
>> Am 09.05.2011 um 22:14 schrieb Peter Kümmel:
>>
>>> On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
Hi everyone,
As a typical start of a new release cycle I want to poll
- what featu
On 09.05.2011 22:56, Stephan Witt wrote:
Am 09.05.2011 um 22:14 schrieb Peter Kümmel:
On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
Hi everyone,
As a typical start of a new release cycle I want to poll
- what features are a must in the next release;
- what work do you think you will be d
Am 09.05.2011 um 22:14 schrieb Peter Kümmel:
> On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
>> Hi everyone,
>>
>> As a typical start of a new release cycle I want to poll
>> - what features are a must in the next release;
>> - what work do you think you will be doing;
>> - what do you hope
On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
Hi everyone,
As a typical start of a new release cycle I want to poll
- what features are a must in the next release;
- what work do you think you will be doing;
- what do you hope to see somebody else to do (please keep it realistic) ?
I will
On 2011-05-06, Jean-Marc Lasgouttes wrote:
> Le 06/05/2011 21:18, Guenter Milde a écrit :
>>> I am sure Qt gives us this information. We should react to OS-level
>>> language change. This is probably trivial.
>> There are some tricky points: the OS typically switches keyboard
>> layout, but the ma
Il 06/05/2011 16:46, Sam Lewis ha scritto:
From: Tommaso Cucinotta
More concretely, for collaboration purposes I would propose to add a relatively
simple missing feature, which is a good history browser.
For example, it could be docked panel that shows up on the left, where you can
see all the co
Am Samstag, 7. Mai 2011 schrieb Peter Kümmel:
> On 06.05.2011 11:00, Jean-Marc Lasgouttes wrote:
> > Le 05/05/2011 21:35, Peter Kümmel a écrit :
> >> On 05.05.2011 14:55, Kornel wrote:
> - NLS disabled by default
> >>>
> >>> Formerly it was enabled by default, but after some discussions Peter
On 06.05.2011 11:00, Jean-Marc Lasgouttes wrote:
Le 05/05/2011 21:35, Peter Kümmel a écrit :
On 05.05.2011 14:55, Kornel wrote:
- NLS disabled by default
Formerly it was enabled by default, but after some discussions Peter
change it
It was too annoying to always having build all the .po stu
On 06.05.2011 11:01, Jean-Marc Lasgouttes wrote:
Le 05/05/2011 22:32, Peter Kümmel a écrit :
This removes the patch for
http://www.lyx.org/trac/ticket/7407
locale_init(); asserts and the try/catch doesn't help.
Tried it again, seems I was wrong.
The trick is that now locale_init is in the
Le 06/05/2011 21:18, Guenter Milde a écrit :
I am sure Qt gives us this information. We should react to OS-level
language change. This is probably trivial.
There are some tricky points: the OS typically switches keyboard
layout, but the mapping of keyboard-layout to intended document
language i
Le 06/05/2011 21:18, Kornel a écrit :
> +#cmakedefine LYX_EXTERNAL_LIBINTL 1
> for my enlightment, what does this do?
Defines the macro LYX_EXTERNAL_LIBINTL according to the cmake value
${LYX_EXTERNAL_LIBINTL}
This means
if ${LYX_EXTERNAL_LIBINTL}
==> #define LYX_EXTERNAL_LIBINTL 1
else
On Wed, May 4, 2011 at 10:48 PM, Rob Oakes wrote:
> But, in LyX's defense, it's a very complicated book and the export time is
> pretty comparable to what I'd get in InDesign or Scribus. LyX is far
> superior, though, because this book would be prohibitively difficult in
> either program. (Prob
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 18:29, Kornel a écrit :
> > Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
> > break
> > Lyx behaves ok ...
> >
> > Ataching the patch.
>
> Go ahead if it works.
>
> Small nit:
>
> +#cmakedefine LY
On 2011-05-06, Jean-Marc Lasgouttes wrote:
> Le 06/05/11 17:23, Richman Reuven a écrit :
>> * recognizing the os-es language change, i'm not sure how it works for
>> other languages but a common solution for english/hebrew switching is
>> using f12, i always wonder why? ^_^*
> I am sure Qt gives u
Am 06.05.2011 um 20:04 schrieb Jean-Marc Lasgouttes:
> Le 06/05/2011 18:29, Kornel a écrit :
>> Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
>> break
>> Lyx behaves ok ...
>>
>> Ataching the patch.
>
> Go ahead if it works.
I tried it and it compiles and LyX starts.
Le 06/05/2011 18:29, Kornel a écrit :
Thanks Jean-Marc. Will check now, if the defines in config.h.cmake don't
break
Lyx behaves ok ...
Ataching the patch.
Go ahead if it works.
Small nit:
+#cmakedefine LYX_EXTERNAL_LIBINTL 1
for my enlightment, what does this do?
+#if !defined(LYX_EXTERN
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 06/05/11 17:50, Kornel a écrit :
> > But it is your work. It would be disingenuous.
> >
> > I will prepare a patch, but you should commit.
>
> Seriously, it is more important for me to have all the cmake code
> passing through your hands.
Le 06/05/11 17:50, Kornel a écrit :
But it is your work. It would be disingenuous.
I will prepare a patch, but you should commit.
Seriously, it is more important for me to have all the cmake code
passing through your hands.
JMarc
Am Freitag, 6. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 05/05/11 17:19, Kornel a écrit :
> > You did. Sorry. Compiling now.
> >
> > Ok, two glitches ...
>
> Feel free to commit it once/if you are satisfied by it.
>
> JMarc
But it is your work. It would be disingenuous.
I will prepare a p
Le 06/05/11 17:23, Richman Reuven a écrit :
* recognizing the os-es language change, i'm not sure how it works for
other languages but a common solution for english/hebrew switching is
using f12, i always wonder why? ^_^*
I am sure Qt gives us this information. We should react to OS-level
lang
On Wed, 2011-05-04 at 00:50 +0200, Vincent van Ravesteijn wrote:
> Hi everyone,
>
> As a typical start of a new release cycle I want to poll
> - what features are a must in the next release;
> - what work do you think you will be doing;
> - what do you hope to see somebody else to do (please ke
- Original Message -
> From: Tommaso Cucinotta
> More concretely, for collaboration purposes I would propose to add a
> relatively
> simple missing feature, which is a good history browser.
> For example, it could be docked panel that shows up on the left, where you
> can
> see all th
Le 05/05/11 17:19, Kornel a écrit :
You did. Sorry. Compiling now.
Ok, two glitches ...
Feel free to commit it once/if you are satisfied by it.
JMarc
- Original Message -
> From: Tommaso Cucinotta
> So, why having a git-based file format ?
I was under the impressions that the point of a taped or zip format was that
all relevant files bibliography, graphics, and lyx file would be committed/
pushed at once via the LyX interface. Mayb
Il 06/05/2011 14:50, Tommaso Cucinotta ha scritto:
So, why having a git-based file format ?
More concretely, for collaboration purposes I would propose to add a
relatively simple missing feature, which is a good history browser.
For example, it could be docked panel that shows up on the left,
Il 06/05/2011 12:12, Sam Lewis ha scritto:
- Original Message -
From: Abdelrazak Younes
But my vision is going much farther than just a file to be interchanged. At the
end, we could very well work from within LyX without sending anything, LyX would
take care of cloning, pushing and pull
- Original Message -
> From: Abdelrazak Younes
> But my vision is going much farther than just a file to be interchanged. At
> the
> end, we could very well work from within LyX without sending anything, LyX
> would
> take care of cloning, pushing and pulling, etc. People would then b
> >> Lua
> >>+ small and fast,
> >>+ used in LuaTeX, so it will become more common and known in the
> >> TeX community,
> >>+ a Lua interpreter can be embedded in LyX with minimal
> impact on
> >> the binary size.
>
> > Wasn't there another thread with the result that LyX is
Kornel wrote:
> Nonetheless I don't like messed source, but I like at the same time
> to have remerged files which I can edit. They are there witch correct marked
> source lines.
> I use this info to resolve the meaning of some strings.
>
> And comparing some po-files (de sk cz pl) is easier, sin
On 2011-05-05, Peter Kümmel wrote:
> On 05.05.2011 10:28, Guenter Milde wrote:
>> As language I'd use one of:
>> Lua
>>+ small and fast,
>>+ used in LuaTeX, so it will become more common and known in the
>> TeX community,
>>+ a Lua interpreter can be embedded in LyX with minimal
Le 05/05/2011 22:32, Peter Kümmel a écrit :
This removes the patch for
http://www.lyx.org/trac/ticket/7407
locale_init(); asserts and the try/catch doesn't help.
Tried it again, seems I was wrong.
The trick is that now locale_init is in the try {} part and does not get
invoked when there
Le 05/05/2011 21:35, Peter Kümmel a écrit :
On 05.05.2011 14:55, Kornel wrote:
- NLS disabled by default
Formerly it was enabled by default, but after some discussions Peter
change it
It was too annoying to always having build all the .po stuff when you
wanna only
work on on C++ code. For in
Am Freitag, 6. Mai 2011 schrieb Pavel Sanda:
> Kornel wrote:
> > Every so often there were svn-conflicts,
>
> po conflicts are seldom under autotools (ie the remerge isn't done for each
> build).
>
> > either I was forced to remove the created po-files, or I had to commit
> > the remerged.
>
> s
> I think I have quite an uncommon opinion (among LyX developers) about
> what LFUNs are causing (perhaps as a side effect) in the LyX code.
> Basically, many classes use this machinery to invoke operations, with
> the result that sometimes the class does not get a properly designed
> interface
Il 05/05/2011 22:40, venom00 ha scritto:
My idea was to issue commands to LyX via LFUNs, which are
quite stable, even because they're associated with
customizable shortcuts. I think this is a very uninvasive approach.
For the language I prefer Python because _a lot_ of people
uses it and I thi
On 6-5-2011 8:37, Peter Kümmel wrote:
> And who collects all the ideas from this 100+ thread?
I do.
Vincent
venom00 wrote:
> > And who collects all the ideas from this 100+ thread?
> >
> > When extending the list we should post the complete list.
> > And discussion should not be done within the list.
>
> A wiki page?
this sounds nice idea, but i doesn't work in practise looking for last two
attempts
Kornel wrote:
> Every so often there were svn-conflicts,
po conflicts are seldom under autotools (ie the remerge isn't done for each
build).
> either I was forced to remove the created po-files, or I had to commit the
> remerged.
svn revert *.po //git checkout -f
> At that time the created po
> And who collects all the ideas from this 100+ thread?
>
> When extending the list we should post the complete list.
> And discussion should not be done within the list.
A wiki page?
venom00
And who collects all the ideas from this 100+ thread?
When extending the list we should post the complete list.
And discussion should not be done within the list.
Peter
On 06.05.2011 08:22, Liviu Andronic wrote:
On Wed, May 4, 2011 at 12:50 AM, Vincent van Ravesteijn wrote:
- what features
On Wed, May 4, 2011 at 12:50 AM, Vincent van Ravesteijn wrote:
> - what features are a must in the next release;
>
- Native support for beamer fragile environments (#7273)
- Improve UI for Argument Entry (#6753)
- A reliable LyX -> TeX -> LyX cycle
- Improved config UI for Natbib (#6777)
- "Paste
Am Donnerstag, 5. Mai 2011 schrieb Pavel Sanda:
> Kornel wrote:
> > What do you miss in cmake? I tried to (somehow) mimic all I was aware of
> > from autotools.
>
> remerge of strings should be possible without any additional copying of
> files.
>
> pavel
This is trivial, really. I had hard tim
On 04/05/2011 1:38 PM, Enrico Forestieri wrote:
On Wed, May 04, 2011 at 06:58:33PM +0200, Vincent van Ravesteijn wrote:
I think that more attention should be put in the memory footprint. I have
the impression that LyX is becoming a bloatware.
Apart from which features are (un)necessary, can
On 04/05/2011 12:32 PM, José Matos wrote:
On Wednesday 04 May 2011 13:26:51 Abdelrazak Younes wrote:
Cleanup and refactoring:
* Fix (rewrite) the graphics backend mess.
... and finally merging graphics with external insets?
That has been the holly grail for the last eleven years. :-)
+1
--
On 03/05/2011 6:50 PM, Vincent van Ravesteijn wrote:
Hi everyone,
As a typical start of a new release cycle I want to poll
- what features are a must in the next release;
- Support for \macros without arguments.
- A better UI for Opt and Req arguments.
- what work do you think you will be do
Peter Kümmel wrote:
> It was too annoying to always having build all the .po stuff when you wanna
> only
> work on on C++ code. For installing it is needed, sure. But as default?
like with autotools you dont need to rebuild all po stuff when compiling.
you must do harsh things in po/ that some bu
Kornel wrote:
> What do you miss in cmake? I tried to (somehow) mimic all I was aware of
> from autotools.
remerge of strings should be possible without any additional copying of files.
pavel
> > My idea was to issue commands to LyX via LFUNs, which are
> quite stable, even because they're associated with
> customizable shortcuts. I think this is a very uninvasive approach.
> > For the language I prefer Python because _a lot_ of people
> uses it and I think this is fundamental if we
On 05.05.2011 21:39, Peter Kümmel wrote:
On 05.05.2011 13:50, Jean-Marc Lasgouttes wrote:
Here is my patch for included libintl. Part of it is a IMO better fix to
the startup assertion encountered with cmake. I guess the code is not
linked against libintl, because I get
Index: development/cmake
On 05.05.2011 19:26, venom00 wrote:
Jean Marc said:
The problem with script plugins is that people seem to expect that by
linking LyX to python everybody will be able to write python scritps
that can manipulate LyX objects natively.
I may be missing most of current advancement in programming
to
On 05.05.2011 10:28, Guenter Milde wrote:
As language I'd use one of:
Lua
+ small and fast,
+ used in LuaTeX, so it will become more common and known in the
TeX community,
+ a Lua interpreter can be embedded in LyX with minimal impact on
the binary size.
Wasn't there anothe
On 05.05.2011 13:50, Jean-Marc Lasgouttes wrote:
Here is my patch for included libintl. Part of it is a IMO better fix to
the startup assertion encountered with cmake. I guess the code is not
linked against libintl, because I get
Index: development/cmake/config.h.cmake
Index: src/LyX.cpp
===
On 05.05.2011 14:55, Kornel wrote:
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
Le 05/05/11 12:34, Kornel a écrit :
What do you miss in cmake? I tried to (somehow) mimic all I was aware of
from autotools.
It surely is more then 80% ...
From the top of my head (I ask for forgiv
On 05.05.2011 11:17, Jean-Marc Lasgouttes wrote:
Le 04/05/11 20:28, José Matos a écrit :
On Wednesday 04 May 2011 18:58:34 Peter Kümmel wrote:
I assume as long as we have a 80 character limit we will have autotools.
??
I do not follow the logic. :-)
I have the impression that often peopl
Le 04/05/2011 16:39, Stephan Witt a écrit :
Features:
* Correct the drawing of ligatures and kerning
I repeat the plan I proposed for the record: do both metrics and drawing
at word level and when one needs to draw the cursor, compute the metrics
of the word up to the cursor.
I think this
Jean Marc said:
> The problem with script plugins is that people seem to expect that by
> linking LyX to python everybody will be able to write python scritps
> that can manipulate LyX objects natively.
>
> I may be missing most of current advancement in programming
> tools, but I
> do not see
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 05/05/11 15:08, Kornel a écrit :
> > Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> > > - building internal LIBINTL does not work. I have a unfinished patch
> > > for
> > >
> > > this
> >
> > Could you give me the patch
Le 05/05/11 14:55, Kornel a écrit :
> - NLS disabled by default
Formerly it was enabled by default, but after some discussions Peter
change it
It should eventually be on by default.
> - does not work in place by default (actually build_support_dir stuff
> should be removed now, but I have
Le 05/05/11 15:08, Kornel a écrit :
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> - building internal LIBINTL does not work. I have a unfinished patch for
> this
Could you give me the patch to try? It is not compilable here too.
...
Didn't I send it?
JMarc
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> - building internal LIBINTL does not work. I have a unfinished patch for
> this
Could you give me the patch to try? It is not compilable here too.
...
In file included from /usr/src/lyx/lyx-devel/intl/bindtextdom.c:27:
/usr/src/lyx/lyx-de
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 05/05/11 12:34, Kornel a écrit :
> > What do you miss in cmake? I tried to (somehow) mimic all I was aware of
> > from autotools.
> >
> > It surely is more then 80% ...
>
> From the top of my head (I ask for forgiveness if some accusa
Le 05/05/11 14:01, Vincent van Ravesteijn a écrit :
- what does LYX_DEVEL_VERSION do? What is the difference with LYX_RELEASE=OFF?
This sets the DEVEL_VERSION #define. Grep the LyX source to see where it is
used.
I think these options should be rationalized and streamlined. This
LYX_DEVEL
> - what does LYX_DEVEL_VERSION do? What is the difference with LYX_RELEASE=OFF?
This sets the DEVEL_VERSION #define. Grep the LyX source to see where it is
used.
Vincent
Le 05/05/11 12:34, Kornel a écrit :
What do you miss in cmake? I tried to (somehow) mimic all I was aware of
from autotools.
It surely is more then 80% ...
From the top of my head (I ask for forgiveness if some accusations are
unfounded, this is from memory)
- NLS disabled by default
- I do
Am Donnerstag, 5. Mai 2011 schrieb Jean-Marc Lasgouttes:
> Le 04/05/11 18:57, Abdelrazak Younes a écrit :
> >> So I'd say currently CMake is useful but without it I'm able to work.
> >> Without automake currently we have nothing to distribute.
> >
> > So we have to work on it... and I am confident
On 05/05/2011 11:12, Jean-Marc Lasgouttes wrote:
Le 04/05/11 18:57, Abdelrazak Younes a écrit :
So I'd say currently CMake is useful but without it I'm able to work.
Without automake currently we have nothing to distribute.
So we have to work on it... and I am confident that it is possible to
On 05/05/2011 11:13, Stephan Witt wrote:
Am 05.05.2011 um 10:55 schrieb Liviu Andronic:
On Thu, May 5, 2011 at 10:52 AM, Stephan Witt wrote:
Aren't the 'Bundle LyX' and 'GIT LyX' "feature" somehow orthogonal?
Abdel characterized the Embedded GIT format as equivalent (or similar)
in scope to
Le 05/05/11 10:28, Guenter Milde a écrit :
Using a script language for extensions/plugins will raise this
probability significantly.
As language I'd use one of:
The problem with script plugins is that people seem to expect that by
linking LyX to python everybody will be able to write python s
Le 04/05/11 20:28, José Matos a écrit :
On Wednesday 04 May 2011 18:58:34 Peter Kümmel wrote:
I assume as long as we have a 80 character limit we will have autotools.
??
I do not follow the logic. :-)
Just that people are getting exited by the 2.0 release.
JMarc
Am 05.05.2011 um 10:55 schrieb Liviu Andronic:
> On Thu, May 5, 2011 at 10:52 AM, Stephan Witt wrote:
>> Aren't the 'Bundle LyX' and 'GIT LyX' "feature" somehow orthogonal?
>>
> Abdel characterized the Embedded GIT format as equivalent (or similar)
> in scope to the current ZIP archive, which is
Le 04/05/11 18:57, Abdelrazak Younes a écrit :
So I'd say currently CMake is useful but without it I'm able to work.
Without automake currently we have nothing to distribute.
So we have to work on it... and I am confident that it is possible to
achieve that. I hope I can find the time to explor
On 05/05/2011 10:31, Pavel Sanda wrote:
Liviu Andronic wrote:
On Thu, May 5, 2011 at 10:08 AM, Guenter Milde wrote:
"elyx" might be confusing (as it does not have any relation to the "elyxer"
LyX->HTML converter).
We could consider 'blyx' (from Bundle LyX) or 'glyx' (from GIT LyX).
whatsoev
Stephan Witt wrote:
> Am 05.05.2011 um 10:22 schrieb Liviu Andronic:
>
> > On Thu, May 5, 2011 at 10:08 AM, Guenter Milde
> > wrote:
> >> "elyx" might be confusing (as it does not have any relation to the "elyxer"
> >> LyX->HTML converter).
> >>
> > We could consider 'blyx' (from Bundle LyX) or
On Thu, May 5, 2011 at 10:52 AM, Stephan Witt wrote:
> Aren't the 'Bundle LyX' and 'GIT LyX' "feature" somehow orthogonal?
>
Abdel characterized the Embedded GIT format as equivalent (or similar)
in scope to the current ZIP archive, which is a "bundled LyX format".
Liviu
Am 05.05.2011 um 10:22 schrieb Liviu Andronic:
> On Thu, May 5, 2011 at 10:08 AM, Guenter Milde wrote:
>> "elyx" might be confusing (as it does not have any relation to the "elyxer"
>> LyX->HTML converter).
>>
> We could consider 'blyx' (from Bundle LyX) or 'glyx' (from GIT LyX).
> Naming aside,
On Thu, May 5, 2011 at 10:40 AM, Pavel Sanda wrote:
> and LaTeX is just for bumble-bees
> who don't care about stability.
>
So much for 'hard' LyX users. :)
Liviu
José Matos wrote:
> On Wednesday 04 May 2011 22:06:36 Enrico Forestieri wrote:
> > No doubt. However, one uses LyX instead of straight LaTeX because in LyX
> > there are so much buttons and menus to explore, while LaTeX would require
> > reading documentation. The same is true as regards autotools
On Wednesday 04 May 2011 22:06:36 Enrico Forestieri wrote:
> No doubt. However, one uses LyX instead of straight LaTeX because in LyX
> there are so much buttons and menus to explore, while LaTeX would require
> reading documentation. The same is true as regards autotools and cmake,
> I think. So,
Liviu Andronic wrote:
> On Thu, May 5, 2011 at 10:08 AM, Guenter Milde wrote:
> > "elyx" might be confusing (as it does not have any relation to the "elyxer"
> > LyX->HTML converter).
> >
> We could consider 'blyx' (from Bundle LyX) or 'glyx' (from GIT LyX).
whatsoever will be chosen i think we s
On 2011-05-04, Andre Poenitz wrote:
> On Wed, May 04, 2011 at 05:27:36PM +0200, Tommaso Cucinotta wrote:
>> Il 04/05/2011 17:16, Rob Oakes ha scritto:
...
>> Also, if really we have too many features, what about trying to
>> embed some modularity in LyX and make them dynamically loadable
>> on-de
On Thu, May 5, 2011 at 10:08 AM, Guenter Milde wrote:
> "elyx" might be confusing (as it does not have any relation to the "elyxer"
> LyX->HTML converter).
>
We could consider 'blyx' (from Bundle LyX) or 'glyx' (from GIT LyX).
Naming aside, it would be very impressive (!) if a bundle format can
be
On 2011-05-04, Rob Oakes wrote:
>> The user won't see git at all. The user would see a new embedded lyx
>> format, we can call it elyx for example.
I know this is still in the very early planning state, nevertheless I
cannot resist to give an early warning:
"elyx" might be confusing (as it does
On 05/04/2011 04:48 PM, Rob Oakes wrote:
On May 4, 2011, at 2:38 PM, Pavel Sanda wrote:
Rob Oakes wrote:
The book I've been working on takes nearly 15 minutes to compile.\
this looks horrible. what hardware and OS do you use?
Not looks, is horrible.
But, in LyX's defense, it's a very comp
On Wed, May 04, 2011 at 07:45:44PM +0200, Peter Kümmel wrote:
> On 04.05.2011 14:26, Abdelrazak Younes wrote:
> >On 04/05/2011 00:50, Vincent van Ravesteijn wrote:
> >>Hi everyone,
> >>As a typical start of a new release cycle I want to poll
> >>- what features are a must in the next release;
> >
>
On Wed, May 04, 2011 at 05:27:36PM +0200, Tommaso Cucinotta wrote:
> Il 04/05/2011 17:16, Rob Oakes ha scritto:
> >
> >>Software bloat is a term used to describe the tendency of newer computer
> >>programs to have a larger installation footprint, or have many unnecessary
> >>features that are not u
Le 04/05/11 16:52, Abdelrazak Younes a écrit :
On 04/05/2011 16:32, Enrico Forestieri wrote:
On Wed, May 04, 2011 at 03:54:32PM +0200, Abdelrazak Younes wrote:
* Use CMake as our build system for all platforms
I am strongly against this.
I should have said:
* Use CMake as our _main_ build s
On Wed, May 04, 2011 at 09:21:56PM +0100, José Matos wrote:
> On Wednesday 04 May 2011 20:00:06 Enrico Forestieri wrote:
> > He means that who prefers the 80 chars limit also likes autotools.
>
> Has he (royal he) read the files created by automake? :-)
>
> No 80 chars limits anywhere. :-D
I thi
On May 4, 2011, at 10:14 AM, Stephan Witt wrote:
> Am 04.05.2011 um 18:57 schrieb Abdelrazak Younes:
>
>> Wouldn't it be nice if you could generate the .app bundle right from within
>> XCode?
>
> Not really. I promised to provide the .app bundle as nightly build - by a
> cron job.
> I don't k
On May 4, 2011, at 2:38 PM, Pavel Sanda wrote:
> Rob Oakes wrote:
>> The book I've been working on takes nearly 15 minutes to compile.\
> this looks horrible. what hardware and OS do you use?
Not looks, is horrible.
But, in LyX's defense, it's a very complicated book and the export time is
p
On Wed, May 4, 2011 at 7:38 PM, Enrico Forestieri wrote:
> On Wed, May 04, 2011 at 06:58:33PM +0200, Vincent van Ravesteijn wrote:
> > >
> > >
> > > I think that more attention should be put in the memory footprint. I
> have
> > > the impression that LyX is becoming a bloatware.
> > >
> > >
> >
Rob Oakes wrote:
> The book I've been working on takes nearly 15 minutes to compile.
this looks horrible. what hardware and OS do you use? how many pages
of text and pictures? any external-insets processing?
does it change with second run when image cache is active?
pavel
>> Again, I am not going to point the finger against something in particular.
>> I would like that major attention be paid to the increasead bloat with
>> respect to the benefits that come from a particular feature.
>>
>> As it is clear that I was against the export in thread/qprocess features,
>>
1 - 100 of 173 matches
Mail list logo
