[EMAIL PROTECTED] wrote:
On Thu, 21 Feb 2008, Abdelrazak Younes wrote:
How about this as the second paragraph, might be to complicated though...
In a week or two, the developers plan to release a first alpha version
of LyX 1.6.0. This will be the first release in the coming 1.6-series,
which
On Thu, 21 Feb 2008 14:49:12 -0500
rgheck <[EMAIL PROTECTED]> wrote:
> Abdelrazak Younes wrote:
> > Richard Heck wrote:
> >> Richard Heck wrote:
> >>> José Matos wrote:
> After Richard fix I get an assertion.
>
>
> >>> The problem is that lcolor.getX11Name(Color_shadedbg), on
>
On Thu, 21 Feb 2008, Abdelrazak Younes wrote:
How about this as the second paragraph, might be to complicated though...
In a week or two, the developers plan to release a first alpha version of
LyX 1.6.0. This will be the first release in the coming 1.6-series, which
as usual include changes t
Stefan Schimanski wrote:
As I see this here now: this it_ was a first start to improve the
performance of the (long-)words set in the Buffer. This is used to store
the long words for the completion popup. Now the problem are these
requirements:
1. the semantics of a set, i.e. every item sho
rgheck wrote:
Jean-Marc Lasgouttes wrote:
Andre Poenitz
<[EMAIL PROTECTED]>
writes:
I personally don't have a problem with hex numbers for colors. But I
have no strong opinion on the whole subject.
That would not be a bad solution.
Is there some easy way to tell in svn who put th
Pavel Sanda wrote:
Well, the set is a sorted container by definition, see here:
you are right. still i feel there is something strange in set[i] operation :)
The completion popup accesses this containter in a random access way.
Though probably it would be enough to speed up the first
Jean-Marc Lasgouttes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
I personally don't have a problem with hex numbers for colors. But I
have no strong opinion on the whole subject.
That would not be a bad solution.
Is there some easy way to tell in svn who put this code there?
> Well, the set is a sorted container by definition, see here:
you are right. still i feel there is something strange in set[i] operation :)
> The completion popup accesses this containter in a random access way.
> Though probably it would be enough to speed up the first access (e.g. for
> the
Am 22.02.2008 um 00:56 schrieb Pavel Sanda:
easy. But 2 is not supported as far as I could see. Without knowing
the
implementation details, I wonder why. It wouldn't be hard to put
"counters"
into the nodes of the red-black-tree, which count the number of
children.
But it seems this is no
> easy. But 2 is not supported as far as I could see. Without knowing the
> implementation details, I wonder why. It wouldn't be hard to put "counters"
> into the nodes of the red-black-tree, which count the number of children.
> But it seems this is not implemented.
why it should be supported
See my other mail on the list about exactly this problem. The set
is not
the right containter, but vector isn't either... Let's wait for some
conclusion before optimising for the trash here.
Well, add 'no additional includes if they are not absolutely needed'
to
your set of requirements the
On Fri, Feb 22, 2008 at 12:35:16AM +0100, Stefan Schimanski wrote:
>
> Am 22.02.2008 um 00:33 schrieb Andre Poenitz:
>
>> On Fri, Feb 22, 2008 at 12:27:15AM +0100, Stefan Schimanski wrote:
>>> I return a const pointer now. The shared pointer is not really essential
>>> here because the ownership is
Am 22.02.2008 um 00:33 schrieb Andre Poenitz:
On Fri, Feb 22, 2008 at 12:27:15AM +0100, Stefan Schimanski wrote:
I return a const pointer now. The shared pointer is not really
essential
here because the ownership is clear enough.
Better.
The deque does not have to appear in the header eit
On Fri, Feb 22, 2008 at 12:27:15AM +0100, Stefan Schimanski wrote:
> I return a const pointer now. The shared pointer is not really essential
> here because the ownership is clear enough.
Better.
The deque does not have to appear in the header either, it's private
static data anyway...
And I ju
Am 22.02.2008 um 00:24 schrieb Andre Poenitz:
On Fri, Feb 22, 2008 at 12:17:38AM +0100, Stefan Schimanski wrote:
Am 22.02.2008 um 00:13 schrieb Andre Poenitz:
Stefan,
it might be a bit late in the game, but having #include
that you added in revision 23104 in Inset.h is not acceptable.
On Fri, Feb 22, 2008 at 12:17:38AM +0100, Stefan Schimanski wrote:
>
> Am 22.02.2008 um 00:13 schrieb Andre Poenitz:
>
>>
>> Stefan,
>>
>> it might be a bit late in the game, but having #include
>>
>> that you added in revision 23104 in Inset.h is not acceptable. This adds
>> more than 17000 line
Abdelrazak Younes wrote:
FYI, I implemented just that before 1.5.0 and part of the code is still
there commented out. Unfortunately, it was rejected then for the very
same reason as now. I too think this option would be useful. One use
case I can think of besides the other you already cited:
Am 22.02.2008 um 00:13 schrieb Andre Poenitz:
Stefan,
it might be a bit late in the game, but having #include shared_ptr.hpp>
that you added in revision 23104 in Inset.h is not acceptable. This
adds
more than 17000 lines to each compilation unit where it was not used
before (and quite a bi
Hi!
I propose this patch to simplify the notifyCursorLeaves mechanism,
which is mainly used to implement the removal of empty script insets
in mathed. The current problem is that the calls to the
notifyCursorLeaves loop, which calls the method for the left insets,
are spread all over the
Stefan,
it might be a bit late in the game, but having #include
that you added in revision 23104 in Inset.h is not acceptable. This adds
more than 17000 lines to each compilation unit where it was not used
before (and quite a bit did not, but Inset.h is #included by almost
everything)
Andre'
>> i guess there will be more transitional problems wrt 4.4 (rc1 here).
>> GuiApplication.cpp: In member function 'void
>> lyx::frontend::GuiApplication::commitData(QSessionManager&)':
>> GuiApplication.cpp:552: error: invalid use of undefined type 'struct
>> QSessionManager'
>
> #include is mis
Modified: lyx-devel/trunk/src/insets/InsetText.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/InsetText.cpp?rev=23113
=
=
=
=
=
=
=
=
==
--- lyx-devel/trunk/src/insets/InsetText.cpp (original)
+++ lyx-devel/tru
> I purposely left RC_VISUAL_CURSOR out of this function, because something
> is fishy about it. AFAICT, this function doesn't do anything... JMarc took
> a look and I think he also wasn't sure about it... So before just fixing
> the warnings, we ought to try and figure out what this function *s
Richard Heck wrote:
LyXFunc.cpp: In function 'void lyxactOnUpdatedPrefs(const
lyx::LyXRC&, const lyx::LyXRC&)':
LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_LIMIT' not
handled in switch
LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_SCROLLBAR'
not handled in sw
Pavel Sanda wrote:
Linking...
CutAndPaste.obj : error LNK2019: unresolved external symbol "public: bool
__thiscall lyx::InsetCollapsable::undefined(void)const "
([EMAIL PROTECTED]@lyx@@QBE_NXZ) referenced in function "void
__cdecl lyx::cap::switchBetweenClasses(class boost::shared_ptrlyx::Text
> Linking...
> CutAndPaste.obj : error LNK2019: unresolved external symbol "public: bool
> __thiscall lyx::InsetCollapsable::undefined(void)const "
> ([EMAIL PROTECTED]@lyx@@QBE_NXZ) referenced in function "void
> __cdecl lyx::cap::switchBetweenClasses(class boost::shared_ptr lyx::TextClass> con
..\..\..\..\src\insets\InsetText.cpp(71) : error C2664:
'std::_Tree<_Traits>::iterator::iterator(std::_Tree_nod<_Traits>::_Node
*,const std::_Tree<_Traits> *)' : cannot convert parameter 1 from
'std::_Tree<_Traits>::const_iterator' to 'std::_Tree_nod<_Traits>::_Node *'
with
[
_
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I personally don't have a problem with hex numbers for colors. But I
> have no strong opinion on the whole subject.
That would not be a bad solution.
JMarc
On Thu, Feb 21, 2008 at 09:28:24PM +0100, Stefan Schimanski wrote:
> If you like statistics about LyX:
>
> http://www.ohloh.net/projects/3881?p=LyX
What a pile of mis-information.
"Over the entire history of the project, 34 developers have
contributed."
Well, lib/CREDITS lists 146 contributors.
Am 21.02.2008 um 21:59 schrieb Andre Poenitz:
On Thu, Feb 21, 2008 at 08:04:19PM -, [EMAIL PROTECTED] wrote:
Author: rgheck
Date: Thu Feb 21 21:04:17 2008
New Revision: 23110
URL: http://www.lyx.org/trac/changeset/23110
Log:
Cosmetics. And silence some warnings.
Modified:
lyx-devel/tr
On Thu, Feb 21, 2008 at 08:04:19PM -, [EMAIL PROTECTED] wrote:
> Author: rgheck
> Date: Thu Feb 21 21:04:17 2008
> New Revision: 23110
>
> URL: http://www.lyx.org/trac/changeset/23110
> Log:
> Cosmetics. And silence some warnings.
>
> Modified:
> lyx-devel/trunk/src/frontends/qt4/GuiCompl
On Thu, Feb 21, 2008 at 10:26:37AM +0100, Abdelrazak Younes wrote:
> Pavel Sanda wrote:
> >>> Then, this is going to be most annoying. Consider that I am skimming
> >>> through a document and an element is off screen. Then, if I try to
> >>> enlarge the window to see it, I am brought back to the cu
On Thu, Feb 21, 2008 at 02:49:12PM -0500, rgheck wrote:
> Abdelrazak Younes wrote:
>> Richard Heck wrote:
>>> Richard Heck wrote:
José Matos wrote:
> After Richard fix I get an assertion.
>
>
The problem is that lcolor.getX11Name(Color_shadedbg), on LaTeXFeatures
line
If you like statistics about LyX:
http://www.ohloh.net/projects/3881?p=LyX
Stefan
rgheck wrote:
Andre Poenitz wrote:
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- inset
Pavel Sanda wrote:
Or 4.4's ;-}
It seems we have a bug there:
http://bugzilla.lyx.org/show_bug.cgi?id=4568
Could somebody have a look?
i guess there will be more transitional problems wrt 4.4 (rc1 here).
GuiApplication.cpp: In member function 'void
lyx::frontend::GuiApplication::commitData
Pavel Sanda wrote:
Pavel Sanda wrote:
Pavel Sanda wrote:
Yes, the left one is for 'minimizing the buffer' or in other words
'closing the tab without closing the buffer'. We need another icon for
it, any artist up there?
The right button is the 'close buffer' one, unchanged. The associated
i
Hi there,
Don't know if you remember Mr Iwami, he's the one who helped us
implement input methods for CJK. It seems that he has prepared a special
edition for Windows Japonese users. He asks us if we could send the
announcement and put it on the web site too. I think this is fair and it
will
Abdelrazak Younes wrote:
Richard Heck wrote:
Richard Heck wrote:
José Matos wrote:
After Richard fix I get an assertion.
The problem is that lcolor.getX11Name(Color_shadedbg), on
LaTeXFeatures line 636, is returning "red". I'll look to see why
this is, but maybe someone else knows?
Th
Commited. Please report any problems with it.
Thanks
Stefan
Am 21.02.2008 um 16:40 schrieb Stefan Schimanski:
Am 21.02.2008 um 16:18 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
there are 2 problems in this: firstly this cause much more
disturbing
spaces of text begining in case
Andre Poenitz wrote:
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- insets/InsetLayo
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
> Andre Poenitz wrote:
>> On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
>>
>>> Index: insets/InsetLayout.h
>>> ===
>>> --- insets/InsetLayout.h(revision 230
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- insets/InsetLayout.h(revision 23079)
+++ insets/InsetLayout.h(working copy)
@@ -23,6 +23,12 @@
>> Or 4.4's ;-}
>
> It seems we have a bug there:
>
> http://bugzilla.lyx.org/show_bug.cgi?id=4568
>
> Could somebody have a look?
i guess there will be more transitional problems wrt 4.4 (rc1 here).
GuiApplication.cpp: In member function 'void
lyx::frontend::GuiApplication::commitData(QSessionM
Am 21.02.2008 um 16:18 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
there are 2 problems in this: firstly this cause much more
disturbing
spaces of text begining in case no icon is available, secondly
images
are not the same width as you have already written.
Maybe we can use a sp
> Pavel Sanda wrote:
>>> Pavel Sanda wrote:
> Yes, the left one is for 'minimizing the buffer' or in other words
> 'closing the tab without closing the buffer'. We need another icon for
> it, any artist up there?
>
> The right button is the 'close buffer' one, unchanged. The a
Edwin Leuven wrote:
Abdelrazak Younes wrote:
The first alpha is coming soon... hurry up!
;-)
why not annouce an official freeze next week for example to give people
like stefan (and tommaso perhaps) some time to commit their stuff?
That would be sensible indeed.
Abdel.
Abdelrazak Younes wrote:
The first alpha is coming soon... hurry up!
;-)
why not annouce an official freeze next week for example to give people
like stefan (and tommaso perhaps) some time to commit their stuff?
Stefan Schimanski wrote:
there are 2 problems in this: firstly this cause much more disturbing
spaces of text begining in case no icon is available, secondly images
are not the same width as you have already written.
Maybe we can use a space-holder icon, and scale others to the same size?
Sol
there are 2 problems in this: firstly this cause much more disturbing
spaces of text begining in case no icon is available, secondly images
are not the same width as you have already written.
Maybe we can use a space-holder icon, and scale others to the same
size?
Solved it already. With a t
On Wednesday 20 February 2008 17:23:43 Juergen Spitzmueller wrote:
> José Matos wrote:
> > Does it works now?
>
> Yes. Please commit to branch as well.
Done.
> Jürgen
--
José Abílio
Pavel Sanda wrote:
Pavel Sanda wrote:
Yes, the left one is for 'minimizing the buffer' or in other words
'closing the tab without closing the buffer'. We need another icon for
it, any artist up there?
The right button is the 'close buffer' one, unchanged. The associated
icon should be rename
> Pavel Sanda wrote:
>>> Yes, the left one is for 'minimizing the buffer' or in other words
>>> 'closing the tab without closing the buffer'. We need another icon for
>>> it, any artist up there?
>>>
>>> The right button is the 'close buffer' one, unchanged. The associated
>>> icon should be ren
Abdelrazak Younes wrote:
Pavel Sanda wrote:
as i played with this... how can be the split view brought back into
unsplit?
Not possible right now because the tab bar and thus the close buttons
are hidden. Either we disable the tabbar hiding or we need a new LFUN to
destroy the current TabWork
> there are 2 problems in this: firstly this cause much more disturbing
> spaces of text begining in case no icon is available, secondly images
> are not the same width as you have already written.
Maybe we can use a space-holder icon, and scale others to the same size?
Bo
Pavel Sanda wrote:
Yes, the left one is for 'minimizing the buffer' or in other words 'closing
the tab without closing the buffer'. We need another icon for it, any
artist up there?
The right button is the 'close buffer' one, unchanged. The associated icon
should be renamed to closebuffer.png
> This bug is reproducible even without resizing:
> 1. scroll a bit so that the cursor is not visible anymore
> 2. hit the keyboard arrow keys to move the cursor or type something
ouch.
p
> Yes, the left one is for 'minimizing the buffer' or in other words 'closing
> the tab without closing the buffer'. We need another icon for it, any
> artist up there?
>
> The right button is the 'close buffer' one, unchanged. The associated icon
> should be renamed to closebuffer.png though.
Pavel Sanda wrote:
i'm sorry Abdel, but your polishment brought the old bugs back :(
1. srollbar is not correct after resize (as Enrico noted, its not a
serious bug,
no problem if remain this way)
Are you sure? For me it works correctly... weird.
maybe you just need the right recipe.
1. o
>> i'm sorry Abdel, but your polishment brought the old bugs back :(
>> 1. srollbar is not correct after resize (as Enrico noted, its not a
>> serious bug,
>>no problem if remain this way)
>
> Are you sure? For me it works correctly... weird.
maybe you just need the right recipe.
1. open docu
Pavel Sanda wrote:
Juergen Spitzmueller wrote:
[EMAIL PROTECTED] wrote:
Introducing LFUN_SPLIT_VIEW
Nice!
Do you plan to support horizontal splitting as well?
Should be easy yes (by adding an "horizontal" argument).
But first we need some more controls of tabs. In particular we need a
'mini
Pavel Sanda wrote:
Then, this is going to be most annoying. Consider that I am skimming
through a document and an element is off screen. Then, if I try to
enlarge the window to see it, I am brought back to the cursor location?
Just tried it. It is really unbearable. I strongly suggest to
revert
> Juergen Spitzmueller wrote:
>> [EMAIL PROTECTED] wrote:
>>> Introducing LFUN_SPLIT_VIEW
>> Nice!
>> Do you plan to support horizontal splitting as well?
>
> Should be easy yes (by adding an "horizontal" argument).
>
> But first we need some more controls of tabs. In particular we need a
> 'minim
Then, this is going to be most annoying. Consider that I am skimming
through a document and an element is off screen. Then, if I try to
enlarge the window to see it, I am brought back to the cursor location?
>>> Just tried it. It is really unbearable. I strongly suggest to
>>> revert
Abdelrazak Younes wrote:
José Matos wrote:
On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote:
Hm, are you sure about that?
I agree with Jürgen, and I agree with Abdel (note that _probably_). :-)
There is no need to be so specific about the number of expected
releases. Tha
José Matos wrote:
>> Hm, are you sure about that?
>
> I agree with Jürgen, and I agree with Abdel (note that _probably_).
Yes, but this will raise expectations ;-)
Anyway, I'll put in something.
Jürgen
José Matos wrote:
On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote:
Hm, are you sure about that?
I agree with Jürgen, and I agree with Abdel (note that _probably_). :-)
There is no need to be so specific about the number of expected releases.
That will free us to release
José Matos wrote:
On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote:
Hm, are you sure about that?
I agree with Jürgen, and I agree with Abdel (note that _probably_). :-)
There is no need to be so specific about the number of expected releases.
That will free us to release
On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote:
> Hm, are you sure about that?
I agree with Jürgen, and I agree with Abdel (note that _probably_). :-)
There is no need to be so specific about the number of expected releases.
That will free us to release when deemed necessar
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
This is probably going to be the penultimate 1.5.x release before LyX
1.6.0
Hm, are you sure about that?
No, hence the 'probably' :-)
Abdel.
Abdelrazak Younes wrote:
> This is probably going to be the penultimate 1.5.x release before LyX
> 1.6.0
Hm, are you sure about that?
Jürgen
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
So maybe we could say something about it in the 1.5.4 announcement?
write something and I'll include it.
We are pleased to announce the release of LyX 1.5.4. This is a
maintenance release that further improves the stability and the
perf
Abdelrazak Younes wrote:
> So maybe we could say something about it in the 1.5.4 announcement?
write something and I'll include it.
Jürgen
José Matos wrote:
In order not to disturb the normal flow I propose to set a release date of
one week after 1.5.4. The rationale is both technical and PR (public
relations) related.
So maybe we could say something about it in the 1.5.4 announcement?
Abdel.
On Thursday 21 February 2008 10:51:59 Abdelrazak Younes wrote:
> We have a problem with Qt4.4 snapshot apparently (bug 4568) but do we
> care? I tend to think not.
I suggest that we don't care for alpha.
For beta OTHO...
> Abdel.
--
José Abílio
José Matos wrote:
On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote:
1.6 development introduced 26 bugs (until further bugs are added of
course):
http://tinyurl.com/2ppsjo
I use trunk for a few months already and I reckon that it is more than
ready for an alpha release. Jose?
I
On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote:
> 1.6 development introduced 26 bugs (until further bugs are added of
> course):
>
> http://tinyurl.com/2ppsjo
>
> I use trunk for a few months already and I reckon that it is more than
> ready for an alpha release. Jose?
I agree. No
Juergen Spitzmueller wrote:
[EMAIL PROTECTED] wrote:
Introducing LFUN_SPLIT_VIEW
Nice!
Do you plan to support horizontal splitting as well?
Should be easy yes (by adding an "horizontal" argument).
But first we need some more controls of tabs. In particular we need a
'minimize' button alon
[EMAIL PROTECTED] wrote:
> Introducing LFUN_SPLIT_VIEW
Nice!
Do you plan to support horizontal splitting as well?
Jürgen
> a bit with it and I must say that the gitk history browsing is bloody
try qgit, its more comfortable i would say.
anyway, once you get into depths of git log & blame parameters you forget about
ui...
its much more speedy thing compared to any clicking once you get accustomed.
pavel
Pavel Sanda wrote:
Then, this is going to be most annoying. Consider that I am skimming
through a document and an element is off screen. Then, if I try to
enlarge the window to see it, I am brought back to the cursor location?
Just tried it. It is really unbearable. I strongly suggest to
revert
>> I am not sure where this comes from...
>
> This is Pavel using Qt4.3' designer. Just open PrefUi.ui in Qt4.2' designer
> and save it.
>
> Pavel, please use Qt4.2 designer in the future.
arrgh i locally compiled Qt4.2 for that reason here. i even changed the
directory
to ~/designer/qt-x11-open
> > Then, this is going to be most annoying. Consider that I am skimming
> > through a document and an element is off screen. Then, if I try to
> > enlarge the window to see it, I am brought back to the cursor location?
>
> Just tried it. It is really unbearable. I strongly suggest to
> revert the
> > i see. imho images should be after text, so all text items are aligned to
> > the left
> > border.
>
> It would be better if images have the same size, and be kept to the
> left. This can avoid irregular spaces after short symbol names.
there are 2 problems in this: firstly this cause much
1.6 development introduced 26 bugs (until further bugs are added of course):
http://tinyurl.com/2ppsjo
I use trunk for a few months already and I reckon that it is more than
ready for an alpha release. Jose?
Abdel.
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 12:24:07PM +0100, Abdelrazak Younes wrote:
Pavel, please use Qt4.2 designer in the future.
Or 4.4's ;-}
It seems we have a bug there:
http://bugzilla.lyx.org/show_bug.cgi?id=4568
Could somebody have a look?
Abdel.
86 matches
Mail list logo
