On Thu, May 19, 2005 at 09:55:51AM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> So, whilst multiple possible frontends is somehow "nice", it's not very
> >> important IMO.
> >
> | Entropy, Angus. That, and human nature. It's like with platform or
> | achite
On Sun, May 22, 2005 at 11:22:14AM +0100, John Levon wrote:
> On Fri, May 20, 2005 at 11:44:54PM +0200, Andre Poenitz wrote:
>
> > > could actually drop with Qt 4 MVC. What bits become unnecessary?
> >
> > Qt 4 uses MVC for e.g. tree views, list views, tables, comboboxes...
> >
> > I don't think
On Fri, May 20, 2005 at 11:44:54PM +0200, Andre Poenitz wrote:
> > could actually drop with Qt 4 MVC. What bits become unnecessary?
>
> Qt 4 uses MVC for e.g. tree views, list views, tables, comboboxes...
>
> I don't think LyX structure will be affected. However, in addition to
Then would we re
On Mon, May 16, 2005 at 09:29:12PM +0100, John Levon wrote:
> On Mon, May 16, 2005 at 09:55:18PM +0200, Andre Poenitz wrote:
>
> > > ControlBranch.C (for example) is pretty trivial,
> >
> > [To a degree that make one wonder whether it is explicitly needed at all
> > ... but you are right.]
>
> I
Angus Leeming <[EMAIL PROTECTED]> writes:
| Oh, sure. That's why you'll note I was not advocating killing the gtk port.
| The XForms port should go, IMO, because it will become too much effort to
| maintain in a unicoded LyX. Personally, I'm not going to invest effort in
| a gtk port, but I'm not
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> So, whilst multiple possible frontends is somehow "nice", it's not very
>> important IMO.
>
| Entropy, Angus. That, and human nature. It's like with platform or
| achitecture independence: if actually using multiple platforms isn't
| forcing you, it _w
On Mon, May 16, 2005 at 09:55:18PM +0200, Andre Poenitz wrote:
> > ControlBranch.C (for example) is pretty trivial,
>
> [To a degree that make one wonder whether it is explicitly needed at all
> ... but you are right.]
I admit to be speaking from a position of ignorance wrt Qt 4, so I could
well
On Mon, May 16, 2005 at 05:23:27PM +0100, John Levon wrote:
> On Mon, May 16, 2005 at 03:42:23PM +0200, Andre Poenitz wrote:
>
> > They seemingly learned a lesson or two. Qt 4 is conceptionally much
> > cleaner than Qt 3 and older.
>
> That's encouraging to hear, I suppose.
The price is that you
On Mon, May 16, 2005 at 03:42:23PM +0200, Andre Poenitz wrote:
> They seemingly learned a lesson or two. Qt 4 is conceptionally much
> cleaner than Qt 3 and older.
That's encouraging to hear, I suppose.
> > Surely you agree that the hard, time consuming stuff is in the core, and
> > it always ha
Andre Poenitz wrote:
> On Mon, May 16, 2005 at 01:03:42PM +0100, John Levon wrote:
>> Or we can just provide a simple interface from lyxrc that uses Qt if the
>> frontend has something. This is just not difficult to do.
>>
>> > > Furthermore, they encourage commingling of frontend code with logic
On Mon, May 16, 2005 at 01:03:42PM +0100, John Levon wrote:
> Or we can just provide a simple interface from lyxrc that uses Qt if the
> frontend has something. This is just not difficult to do.
>
> > > Furthermore, they encourage commingling of frontend code with logic
> > > code, which is just a
> QSettings gives us e.g. (transparent) access to the Windows registry,
> where all the Window native programs put there configuration stuff and
> "everybody" expects it. When not using Qt we've a choice of either
> programming this access ourselves or remain some kind of sevond class
> citizen by
On Mon, May 16, 2005 at 09:22:27AM +0200, Andre Poenitz wrote:
> QSettings gives us e.g. (transparent) access to the Windows registry,
> where all the Window native programs put there configuration stuff and
> "everybody" expects it. When not using Qt we've a choice of either
> programming this ac
On Sun, May 15, 2005 at 09:49:50PM +0200, Michael Schmitt wrote:
> And while the LyX community discusses the pros and cons of various
> frontends, wonders whether there is a need to maintain multiple
> frontends and whether a GUII is a good thing (even though it may not
> longer serve its origin
On Sun, May 15, 2005 at 07:59:12PM +0100, John Levon wrote:
> On Sun, May 15, 2005 at 08:01:50PM +0200, Andre Poenitz wrote:
>
> > > I see no evidence of this. When has it been a burden since Angus did
> > > the dialogs nicely?
> >
> > It prevents us from using all the platform abstraction Qt wou
Andre Poenitz wrote:
> On Sun, May 15, 2005 at 12:52:50PM +0300, Martin Vermeer wrote:
>> Agree... I don't think GUI-I itself is a burden. Rather, it is something
>> we should be doing anyway, but having to accomodate more than one
>> front end forces the issue. Of course every front end brings it
Andre Poenitz wrote:
It prevents us from using all the platform abstraction Qt would give us
for free. QSettings, QProcess etc. We have to use our own home-grown
menu code, our own toolbar code and won't be able to use gimmicks like
floating toolbars at all - unless we invest more time to pu an
abs
On Sun, May 15, 2005 at 08:01:50PM +0200, Andre Poenitz wrote:
> > I see no evidence of this. When has it been a burden since Angus did
> > the dialogs nicely?
>
> It prevents us from using all the platform abstraction Qt would give us
> for free. QSettings, QProcess etc. We have to use our own h
On Sun, May 15, 2005 at 10:01:59AM +0100, John Levon wrote:
> > The GUI-I investment has already payed off by separating GUI and
> > core. Right now and in a foreseeable future, it will be a burden. A
> > big one.
>
> I see no evidence of this. When has it been a burden since Angus did
> the dial
On Sun, May 15, 2005 at 12:52:50PM +0300, Martin Vermeer wrote:
> Agree... I don't think GUI-I itself is a burden. Rather, it is something
> we should be doing anyway, but having to accomodate more than one
> front end forces the issue. Of course every front end brings its own
> overhead, especiall
On Sun, May 15, 2005 at 10:01:59AM +0100, John Levon wrote:
> On Sat, May 14, 2005 at 09:01:37PM +0200, Andre Poenitz wrote:
>
> > The GUI-I investment has already payed off by separating GUI and core.
> > Right now and in a foreseeable future, it will be a burden. A big one.
>
> I see no evidenc
On Sat, May 14, 2005 at 09:01:37PM +0200, Andre Poenitz wrote:
> The GUI-I investment has already payed off by separating GUI and core.
> Right now and in a foreseeable future, it will be a burden. A big one.
I see no evidence of this. When has it been a burden since Angus did the
dialogs nicely?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> The above. I believe the _translator_ load per front end can
Martin> be brought down to close to zero; as for the _coding_ load
Martin> caused by the ongoing evolution of the LyX core code, that of
Martin> course will never be ze
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Code refactoring should be on-going, yes. However, we should
Angus> drop XForms.
Note that we can't drop xforms until gtk stops depending on it.
JMarc
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote:
> Now there I agree. Which is why I think we should not just "drop" any
> front ends. We need at least two more or less useable ones to keep GUI-I
> alive, now that we have it.
GUI-I has done its duty, let it die. What do we _really_
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
> OK, but that tells us also something about the current state of
> incompleteness of GUI-I. Ideally, the front ends should only define a
> set of primitives that the rest of LyX then uses. I am thinking of a
> termcap type parametriza
On Sat, May 14, 2005 at 05:45:55PM +0300, Martin Vermeer wrote:
> OK, but let's then make sure gtk is minimally useable before that. We
> shouldn't lose this investment (in GUI-I, I mean).
The GUI-I investment has already payed off by separating GUI and core.
Right now and in a foreseeable future,
On Sat, May 14, 2005 at 12:42:21PM +0200, Michael Schmitt wrote:
> My initial tests of the Qt frontend told me that it is far away from
> being stable. Actually, it seems like some stuff is broken that worked
> very well in 1.3 before. Once again, I would like to raise the question
> on whether
Martin Vermeer wrote:
>> So, whilst multiple possible frontends is somehow "nice", it's not very
>> important IMO.
>
> Entropy, Angus. That, and human nature. It's like with platform or
> achitecture independence: if actually using multiple platforms isn't
> forcing you, it _will_ slowly decay.
O
On Sat, May 14, 2005 at 04:01:53PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
> > OK, but let's then make sure gtk is minimally useable before that. We
> > shouldn't lose this investment (in GUI-I, I mean).
>
> What is the important legacy of the GUII project? IMO it is the clean and
> un
On Sat, May 14, 2005 at 03:41:50PM +0100, John Levon wrote:
> On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote:
>
> > Yes... but then we should try to move them closer together again. Yes,
> > some differences will remain. We should certainly have only one
> > translatable string cop
Martin Vermeer wrote:
> OK, but let's then make sure gtk is minimally useable before that. We
> shouldn't lose this investment (in GUI-I, I mean).
What is the important legacy of the GUII project? IMO it is the clean and
understandable code that has, eventually, been written. It will be trivial
to
On Sat, May 14, 2005 at 03:33:41PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
> > Now there I agree. Which is why I think we should not just "drop" any
> > front ends. We need at least two more or less useable ones to keep GUI-I
> > alive, now that we have it.
>
> It keeps us 'honest' you
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote:
> Yes... but then we should try to move them closer together again. Yes,
> some differences will remain. We should certainly have only one
> translatable string copy -- located in the common part outside the front
> ends -- for every
Martin Vermeer wrote:
> Now there I agree. Which is why I think we should not just "drop" any
> front ends. We need at least two more or less useable ones to keep GUI-I
> alive, now that we have it.
It keeps us 'honest' you mean? Fine.
> I expect that in 1.5, we can combine much of the work of ge
On Sat, May 14, 2005 at 02:11:21PM +0100, John Levon wrote:
> On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
>
> > OK, but that tells us also something about the current state of
> > incompleteness of GUI-I. Ideally, the front ends should only define a
> > set of primitives that t
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
> OK, but that tells us also something about the current state of
> incompleteness of GUI-I. Ideally, the front ends should only define a
> set of primitives that the rest of LyX then uses. I am thinking of a
> termcap type parametriz
On Sat, May 14, 2005 at 12:19:38PM +0100, John Spray wrote:
> On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote:
> > * send the gnome port to the Attic now.
> Yes. If one ever wants to refer to it it will still be findable. Right
> now it's just confusing to anyone who is new to the reposi
On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote:
> My take on this is that we should
> * have one *official* frontend, Qt, after 1.4 is out.
Makes sense, although whether distributors package it like that is up to
them.
> * send the gnome port to the Attic now.
Yes. If one ever wants to re
Michael Schmitt wrote:
> Once again, I would like to raise the question
> on whether we can really afford to maintain more than one frontend.
> Wouldn't it make sense to remove even the xforms frontend for 1.4? Who
> is actually using/testing it? I think one really good frontend is better
> than tw
Hi,
I am wondering about the role of the various frontends with regard to
LyX 1.4. At least "gnome" and "gtk" are not usable right now and I would
like to propose to
1. remove "gnome" from the CVS because it is no longer used
2. remove all "gtk" files from POTFILES so that gtk messages will not
41 matches
Mail list logo
