Christian Ridderström wrote:
> Actually, the problem can't be that difficult since I had Herbert's patch
> working in Xforms, and it is only since I started over by first adding
> a patch I got form Juergen (for Qt) that nothing is inserted.
Does that problem (nothing inserted) only occur in the q
On Tue, 2 Dec 2003, Angus Leeming wrote:
> Christian Ridderström wrote:
> >
> > I'm working (ok was working before the wiki-stuff sidetracked me) on
> > Herbert's listings (support for the listings package). This ought to
> > be ready (long) before 1.4 I believe. Basically I have a bug in the
> >
Christian Ridderström wrote:
>> Did I miss anything? Or is anybody working on some pet project that
>> shall be included in LyX 1.4?
>
> I'm working (ok was working before the wiki-stuff sidetracked me) on
> Herbert's listings (support for the listings package). This ought to
> be ready (long) bef
On Mon, 1 Dec 2003, Michael Schmitt wrote:
> ***
>
> Did I miss anything? Or is anybody working on some pet project that
> shall be included in LyX 1.4?
I'm working (ok was working before the wiki-stuff sidetracked me) on
Herbert'
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> What we could do is have
>>
>> - a text field for the file name, with a browse button
>>
>> - a combox (less clutter that a list like we have now) with the
>> list of types (== templates), which is set initially to 'auto' (or
>> 'defa
On Mon, Dec 01, 2003 at 06:33:59PM +, Angus Leeming wrote:
> You have my vote too. Which reminds me: I like the mathed approach to
> tables ;-)
But it's harder to move the outer world tables that way...
Andre'
On Monday 01 December 2003 09:48, Michael Schmitt wrote:
> Hello,
>
> I still do not give up hope that LyX 1.4 will eventually become reality.
>
> Since http://www.devel.lyx.org/roadmap.php3 is totally outdated (it
> lists some features that were initially planned for 1.2), I started to
> set up a
Jean-Marc Lasgouttes wrote:
> Andre> Relying on extensions to determine the file type is not very
> Andre> robust. I could e.g. imagine that the mapping extension ->
> Andre> application is not 1:1.
>
> We have some code to guess type by contents already.
>
> Andre> However, from an UI point of v
Andre Poenitz wrote:
> We basically have a choice of making what we have now workable and
> create some fragile glue code (which should be better than we had
> before, but...) or tame that beast for good.
> I am opting for the latter right now as this minimizes total effort
> in the long run.
You
Andre Poenitz wrote:
>> Asger proposed a solution to this. Each dialog could save its
>> 'stateful' variables in files preferences.xforms, preferences.qt
>> etc
> But that's pretty complicated for the dialog author unless this is
> done somehow automatically.
Oh, I'm sure we could automate it, ju
On Mon, Dec 01, 2003 at 05:59:33PM +0100, Michael Schmitt wrote:
> John Levon wrote:
>
> >This is actually 99% of the work. I hope people are beginning to see
> >what a massive task this actually is now ... just getting tables back up
> >and running will probably take *weeks* (sadly, I don't think
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Relying on extensions to determine the file type is not very
Andre> robust. I could e.g. imagine that the mapping extension ->
Andre> application is not 1:1.
We have some code to guess type by contents already.
Andre> However, fro
John Levon wrote:
This is actually 99% of the work. I hope people are beginning to see
what a massive task this actually is now ... just getting tables back up
and running will probably take *weeks* (sadly, I don't think I'm
exaggerating).
And I also hope people are beginning to see that _every_ n
On Mon, Dec 01, 2003 at 05:53:37PM +0100, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> As always, life is a little complicated. The only reason to
> Angus> have two dialogs is to 1. Get rid of that combox (XFig, Raster,
> Angus> Chess, Date) e
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> As always, life is a little complicated. The only reason to
Angus> have two dialogs is to 1. Get rid of that combox (XFig, Raster,
Angus> Chess, Date) etc when we know that we want to insert a graphic.
Angus> However, XFig, Raster,
On Mon, Dec 01, 2003 at 03:52:50PM +, Angus Leeming wrote:
> John Levon wrote:
>
> > On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote:
> >
> >> > So, the need for the combox remains even for 'graphic' files,
> >> > unless we 'pollute' the calling menu Insert->XFig, Insert->Raster
On Mon, Dec 01, 2003 at 03:52:50PM +, Angus Leeming wrote:
> Indeed. Isn't the current, 1.4.x heirarchy something like:
> Insert->XYZ->External Material
> where I forget XYZ, leading to
> Insert->XYZ->XFig, etc.
>
> Of course, we might have a separate 'External' sub menu
>
John Levon wrote:
> On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote:
>
>> > So, the need for the combox remains even for 'graphic' files,
>> > unless we 'pollute' the calling menu Insert->XFig, Insert->Raster
>> > etc.
>>
>> I even like this idea. I'd rather access something in the
On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote:
> > So, the need for the combox remains even for 'graphic' files, unless
> > we 'pollute' the calling menu Insert->XFig, Insert->Raster etc.
>
> I even like this idea. I'd rather access something in the menu
> hierarchy instead of so
On Mon, Dec 01, 2003 at 03:16:33PM +, Angus Leeming wrote:
> So, the need for the combox remains even for 'graphic' files, unless
> we 'pollute' the calling menu Insert->XFig, Insert->Raster etc.
I even like this idea. I'd rather access something in the menu
hierarchy instead of some dialog w
Jean-Marc Lasgouttes wrote:
> Angus> Actually, what you said is that having a single
> Angus> inset that was able to handle any 'external' data
> Angus> (ie InsetExternal) would result in a UI something
> Angus> like that of PowerPoint where a single dialog
> Angus> controls the input of many, con
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Actually, what you said is that having a single inset that was
Angus> able to handle any 'external' data (ie InsetExternal) would
Angus> result in a UI something like that of PowerPoint where a single
Angus> dialog controls the inpu
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> * I think that I would like to give the External inset
> dialogs Angus> the ability to rotate, resize and crop their data.
> This Angus> involves additions to qt/QExternal* and
> xforms/FormExternal
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> * I think that I would like to give the External inset dialogs
Angus> the ability to rotate, resize and crop their data. This
Angus> involves additions to qt/QExternal* and xforms/FormExternal*
Angus> only.
Angus> That would make I
On Mon, Dec 01, 2003 at 01:25:04PM +0100, Andre Poenitz wrote:
> Undo should be checked again.
Undo is (fairly) trivially crashing again
regards
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
On Mon, Dec 01, 2003 at 10:48:13AM +0100, Michael Schmitt wrote:
> set up a new task list covering the remaining open issues of LyX 1.4.
>
> Beside the usual bug fixing, I see the following open issues:
This is actually 99% of the work. I hope people are beginning to see
what a massive task this
Michael Schmitt wrote:
> I still do not give up hope that LyX 1.4 will eventually become
> reality.
As someone noted a wee while ago, the changes in functionality from
1.3 to 1.4 are small. The long lead time does not mean that users are
missing out.
> Optional tasks
>
> - Frontend:
> - Contr
On Mon, Dec 01, 2003 at 10:48:13AM +0100, Michael Schmitt wrote:
> Mandatory tasks
>
> - Kernel
> - General cleanup (details?) (AB, AP)
I think we are "structurally" through.
User interaction with tables is completely broken due to the
one-and-a-half cursor slice limbo. [I am a bit in a di
Hello,
I still do not give up hope that LyX 1.4 will eventually become reality.
Since http://www.devel.lyx.org/roadmap.php3 is totally outdated (it
lists some features that were initially planned for 1.2), I started to
set up a new task list covering the remaining open issues of LyX 1.4.
Besid
29 matches
Mail list logo
