On Fri, 18 Aug 2000, Dekel Tsur wrote:
Imagemagick also support transformation (e.g. convert -rotate 30),
and it can convert from eps to any format (using gs).
It also include a shared library (libmagick).
I'm not sure how useful it is for your purposes, but I'll leave it to you to
do the
On Thu, 17 Aug 2000, Garst R. Reese wrote:
Dekel Tsur wrote:
On Thu, Aug 17, 2000 at 09:44:48AM +0300, Baruch Even wrote:
On 17 Aug 2000, Miyata Shigeru wrote:
Lastly for linear transform of a graphic buffer of X, we may adopt libart
http://www.levien.com/libart/
On Thu, 17 Aug 2000, Baruch Even wrote:
On 17 Aug 2000, Lars Gullik Bjønnes wrote:
Baruch Even [EMAIL PROTECTED] writes:
| It might be a good idea to release soon a lyx-1.1.6-beta1 in order to do
| the testing by those who will need to use the code. It would be a bad idea
| to
On 17-Aug-2000 Lars Gullik Bjønnes wrote:
NEW_INSETS should be enabled at the same time, because:
- keep the fileformat changes localized to on version
- they also use the textinsets and the other insets that
tabular uses, better testing.
- deveopment for
On 17-Aug-2000 Asger K. Alstrup Nielsen wrote:
Juergen has demonstrated this nicely with his excellent work on the
new tabular inset.
Btw, I hope people appreciate the excellent work Juergen and Lars are
doing with the text insets. Their work is very much related to
infrastructure, and
On 17-Aug-2000 Bernd Paysan wrote:
I'm using latext CVS (i.e. the bug report is related to insettabular.C
rev. 1.44, Aug 11). I'll give a more detailed bug report in the following
lines:
For now thanks for the report I will replay to the single points when
I find the time to have a look,
On Fri, 18 Aug 2000, Allan Rae wrote:
I think that taking a break now will be a good idea, we could then try to
aim for better support for GUII in 1.2.0, as far as I looked into it, it
will require quite a bit of work to get LyX fully GUII, quite a bit of its
internals are dependent on X
Attached again is the LyXImage patch, there were some updates to the tree
and it is (for) now against the latest CVS.
I won't be here till at least tuesday and possibly all of next week, if
you find any trouble with the patch don't apply it as I won't be able to
have a good response, I'll try to
While testing the new tabular inset,
I realized that in some cases LaTeX will make a double line where the
tabular inset only displays a single.
To reproduce this, one has to mark two cells which lie side by side both
multicol, then assign a right border line to the left one and a left
border
On Thu, 17 Aug 2000, Allan Rae wrote:
1) As I pointed out, layout isn't handled by kdlgedit. So this
doesn't use it. Is this OK ?
Is this the geometry stuff you were referring to for the copyright dialog?
Yes. I actually had a mail over the weekend from someone who implied Qt
not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's
true. In general, more complex dialogs will require some callbacks. I
think that if we will remove these (empty) files then we will have to
postprocess Glade-generated _interface files which include _callbacks.
I
On Fri, 18 Aug 2000, John Levon wrote:
Yes. I actually had a mail over the weekend from someone who implied Qt
Designer can generate Qt 1.1 only code, which wasn't at all clear from the
tarball of Qt 2.2.beta. If this is true, then we can switch to using that,
and everyone is happy :)
apologies for the post to self, but I got a reply from the guy and it
seems I misunderstood him. The kdevelop branch can be used for both
versions, but not Qt Designer. So it seems there isn't an available dialog
editor :(
Well you tried ;)
Juergen, I tried *very* hard to use Qt
On Fri, 18 Aug 2000, Juergen Vigna wrote:
I guess the callbacks should go into the FormXxx files and so we can
remove this additional files and yes we have to postprocess the .[ch]
files I've seen that already, so if you move the callbacks you use into
the FormXxx implementation I see then
I think that the problem is in the way LyX calls "update" function. For
example, when I press "Undo" in the menu, the "Redo" command is still
disabled. I have to move and click mouse in LyX working area to get it
enabled. I would predict, that the toolbar should have the similar
behavior.
I'll move the callbacks to FormXxx (actually, FormPrint is the only one
that needs it).
Good than we can remove the unneeded files!
Generally, glade produces this file for every project. However, as far as
I have seen it is almost identical each time. You can desire not to
produce
If it's always identical we could just modify it and leave it there as a
class helper function.
true
Well I tracked this down till LyXView::showState which updates the right
things and the toolbar than is updated. If showState is not called there
is no update at all! IMO there has some
Well, I can't reproduce it (or I don't undestand how I can get into this
"tabular" thing :) ). However, if you know any LyX action which changes
its state after you enter tabular from "plain action" to action which can
be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should
On Fri, 18 Aug 2000, Juergen Vigna wrote:
Well, I can't reproduce it (or I don't undestand how I can get into this
"tabular" thing :) ). However, if you know any LyX action which changes
its state after you enter tabular from "plain action" to action which can
be toggled
On 18-Aug-2000 Marko Vendelin wrote:
Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and
LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the
responsibility of the programmer that implements some new action to define
its state this way (we can use
Hi!
(About the e-mail from Baruch Even)
I think that one good idea for writing a port of lyx to win 32 would be
using a GUI that can be used both on unix and Windows.
One option would be gtk (but not gnome)
Other option would be the Fast ligth toolkit (see http://www.fltk.org)
which is a
Just got this from the cpptips mailing list of Allan Clarke, this might be
usefull as an ass keeper for all those uninitialized pointers in our code.
What do you say about adding it to the src/support ?
(And about me disappearing for next week, well that will happen sunday).
--
Baruch Even
Whoever did the new FormDocument, I BLAME YOU!
I've been chasing the last hour or two (after being up all night) chasing
a bug that was supposedly in my code, after chasing it off with the unkind
help of ddd/gdb I found the culprit to be (supposedly, havent verified it
completely) in the
On Sat, 19 Aug 2000, Baruch Even wrote:
Whoever did the new FormDocument, I BLAME YOU!
Sorry for this harsh language, I'm too tired to think anymore. I apologize
if (and even if not) someone got hurt by this. Wouldn't happen again in
the next 8 hours. I Promise! :-)
(I also claim that I'm
On Fri, 18 Aug 2000, Dekel Tsur wrote:
> Imagemagick also support transformation (e.g. convert -rotate 30),
> and it can convert from eps to any format (using gs).
> It also include a shared library (libmagick).
> I'm not sure how useful it is for your purposes, but I'll leave it to you to
> do
On Thu, 17 Aug 2000, Garst R. Reese wrote:
> Dekel Tsur wrote:
> >
> > On Thu, Aug 17, 2000 at 09:44:48AM +0300, Baruch Even wrote:
> > > On 17 Aug 2000, Miyata Shigeru wrote:
> > >
> > > > Lastly for linear transform of a graphic buffer of X, we may adopt libart
> > > >
On Thu, 17 Aug 2000, Baruch Even wrote:
> On 17 Aug 2000, Lars Gullik Bjønnes wrote:
>
> > Baruch Even <[EMAIL PROTECTED]> writes:
> >
> > | It might be a good idea to release soon a lyx-1.1.6-beta1 in order to do
> > | the testing by those who will need to use the code. It would be a bad idea
On 17-Aug-2000 Lars Gullik Bjønnes wrote:
>
> NEW_INSETS should be enabled at the same time, because:
> - keep the fileformat changes localized to on version
> - they also use the textinsets and the other insets that
> tabular uses, better testing.
> -
On 17-Aug-2000 Asger K. Alstrup Nielsen wrote:
> Juergen has demonstrated this nicely with his excellent work on the
> new tabular inset.
>
> Btw, I hope people appreciate the excellent work Juergen and Lars are
> doing with the text insets. Their work is very much related to
> infrastructure,
On 17-Aug-2000 Bernd Paysan wrote:
> I'm using latext CVS (i.e. the bug report is related to insettabular.C
> rev. 1.44, Aug 11). I'll give a more detailed bug report in the following
> lines:
>
For now thanks for the report I will replay to the single points when
I find the time to have a
On Fri, 18 Aug 2000, Allan Rae wrote:
> > I think that taking a break now will be a good idea, we could then try to
> > aim for better support for GUII in 1.2.0, as far as I looked into it, it
> > will require quite a bit of work to get LyX fully GUII, quite a bit of its
> > internals are
Attached again is the LyXImage patch, there were some updates to the tree
and it is (for) now against the latest CVS.
I won't be here till at least tuesday and possibly all of next week, if
you find any trouble with the patch don't apply it as I won't be able to
have a good response, I'll try to
While testing the new tabular inset,
I realized that in some cases LaTeX will make a double line where the
tabular inset only displays a single.
To reproduce this, one has to mark two cells which lie side by side both
multicol, then assign a right border line to the left one and a left
border
On Thu, 17 Aug 2000, Allan Rae wrote:
> > 1) As I pointed out, layout isn't handled by kdlgedit. So this
> >doesn't use it. Is this OK ?
>
> Is this the geometry stuff you were referring to for the copyright dialog?
>
Yes. I actually had a mail over the weekend from someone who implied Qt
>
> not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's
> true. In general, more complex dialogs will require some callbacks. I
> think that if we will remove these (empty) files then we will have to
> postprocess Glade-generated _interface files which include _callbacks.
On Fri, 18 Aug 2000, John Levon wrote:
> Yes. I actually had a mail over the weekend from someone who implied Qt
> Designer can generate Qt 1.1 only code, which wasn't at all clear from the
> tarball of Qt 2.2.beta. If this is true, then we can switch to using that,
> and everyone is happy :)
>
>
> apologies for the post to self, but I got a reply from the guy and it
> seems I misunderstood him. The kdevelop branch can be used for both
> versions, but not Qt Designer. So it seems there isn't an available dialog
> editor :(
>
Well you tried ;)
> Juergen, I tried *very* hard to use Qt
On Fri, 18 Aug 2000, Juergen Vigna wrote:
> I guess the callbacks should go into the FormXxx files and so we can
> remove this additional files and yes we have to postprocess the .[ch]
> files I've seen that already, so if you move the callbacks you use into
> the FormXxx implementation I see
> I think that the problem is in the way LyX calls "update" function. For
> example, when I press "Undo" in the menu, the "Redo" command is still
> disabled. I have to move and click mouse in LyX working area to get it
> enabled. I would predict, that the toolbar should have the similar
>
>
> I'll move the callbacks to FormXxx (actually, FormPrint is the only one
> that needs it).
>
Good than we can remove the unneeded files!
>
> Generally, glade produces this file for every project. However, as far as
> I have seen it is almost identical each time. You can desire not to
>
> If it's always identical we could just modify it and leave it there as a
> class helper function.
true
> Well I tracked this down till LyXView::showState which updates the right
> things and the toolbar than is updated. If showState is not called there
> is no update at all! IMO there has
>
> Well, I can't reproduce it (or I don't undestand how I can get into this
> "tabular" thing :) ). However, if you know any LyX action which changes
> its state after you enter tabular from "plain action" to action which can
> be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you
On Fri, 18 Aug 2000, Juergen Vigna wrote:
> >
> > Well, I can't reproduce it (or I don't undestand how I can get into this
> > "tabular" thing :) ). However, if you know any LyX action which changes
> > its state after you enter tabular from "plain action" to action which can
> > be toggled
On 18-Aug-2000 Marko Vendelin wrote:
>
> Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and
> LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the
> responsibility of the programmer that implements some new action to define
> its state this way (we can use
Hi!
(About the e-mail from Baruch Even)
I think that one good idea for writing a port of lyx to win 32 would be
using a GUI that can be used both on unix and Windows.
One option would be gtk (but not gnome)
Other option would be the Fast ligth toolkit (see http://www.fltk.org)
which is a
Just got this from the cpptips mailing list of Allan Clarke, this might be
usefull as an ass keeper for all those uninitialized pointers in our code.
What do you say about adding it to the src/support ?
(And about me disappearing for next week, well that will happen sunday).
--
Baruch Even
Whoever did the new FormDocument, I BLAME YOU!
I've been chasing the last hour or two (after being up all night) chasing
a bug that was supposedly in my code, after chasing it off with the unkind
help of ddd/gdb I found the culprit to be (supposedly, havent verified it
completely) in the
On Sat, 19 Aug 2000, Baruch Even wrote:
> Whoever did the new FormDocument, I BLAME YOU!
Sorry for this harsh language, I'm too tired to think anymore. I apologize
if (and even if not) someone got hurt by this. Wouldn't happen again in
the next 8 hours. I Promise! :-)
(I also claim that I'm
48 matches
Mail list logo
