Am Dienstag, 30. Mai 2006 11:48 schrieb Charles de Miramon:
Why don't you post a question in kde-core-devel ?
I might do so when I know what I want to ask :-)
I think Trolltech is
folding back in Qt4 some functionalities of KDELibs. Maybe, the light
KDE
port will be easier with Qt4 and
Am Dienstag, 30. Mai 2006 11:48 schrieb Charles de Miramon:
> Why don't you post a question in kde-core-devel ?
I might do so when I know what I want to ask :-)
> I think Trolltech is
> folding back in Qt4 some functionalities of KDELibs. Maybe, the light
KDE
> port will be easier with Qt4
Georg Baum wrote:
I don't know. I never heard of it. I searched a bit and found out that it
is supposed to be in SuSE 9.3 and 10.0 which I use at work, but I did not
notice anything. Certainly the kde file dialog is not used by qt apps.
Georg
Why don't you post a question in
Georg Baum wrote:
>
> I don't know. I never heard of it. I searched a bit and found out that it
> is supposed to be in SuSE 9.3 and 10.0 which I use at work, but I did not
> notice anything. Certainly the kde file dialog is not used by qt apps.
>
>
> Georg
Why don't you post a question in
Georg == Georg Baum [EMAIL PROTECTED] writes:
I did that. Two things for a start: - it would be good if
--with-frontend=kde compiled the qt frontend automatically.
Yes and at runtime, the binary would switch to Qt only is KDE is
not detected. Is this possible?
Georg I guess so, but it
Am Montag, 29. Mai 2006 18:00 schrieb Jean-Marc Lasgouttes:
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg I guess so, but it would involve dynamic loading of libs at run
Georg time, and before anything happens the binary must decide
Georg whether it wants a QApplication or KApplication.
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg I don't know. I never heard of it. I searched a bit and found
Georg out that it is supposed to be in SuSE 9.3 and 10.0 which I use
Georg at work, but I did not notice anything. Certainly the kde file
Georg dialog is not used by qt apps.
It
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> > I did that. Two things for a start: > - it would be good if
>> --with-frontend=kde compiled the qt frontend > automatically.
>>
>> Yes and at runtime, the binary would switch to Qt only is KDE is
>> not detected. Is this possible?
Am Montag, 29. Mai 2006 18:00 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
> Georg> I guess so, but it would involve dynamic loading of libs at run
> Georg> time, and before anything happens the binary must decide
> Georg> whether it wants a QApplication
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I don't know. I never heard of it. I searched a bit and found
Georg> out that it is supposed to be in SuSE 9.3 and 10.0 which I use
Georg> at work, but I did not notice anything. Certainly the kde file
Georg> dialog is not used by qt
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:05 schrieb Juergen Spitzmueller:
I did that. Two things for a start:
- it would be good if --with-frontend=kde compiled the qt frontend
automatically.
Why? It does not need it. Although the sources are shared, the object
files are not.
Juergen Spitzmueller wrote:
.
I'd second that.
Me too.
Cheers,
Charles
--
http://www.kde-france.org
it. Although the sources are shared, the object
files are not.
compiling --with-frontend=kde fails from a fresh tree for me, I needed
--with-frontend=qt kde
I forgot to change one include path. Compiling only the kde frontend works
now for me.
Georg
Index: src/frontends/kde3/moc/Makefile.am
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:11 schrieb Abdelrazak Younes:
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
Currently I simply implemented an additional frontend name kde. It is like
any other frontend, the only difference is
Georg Baum wrote:
> Am Samstag, 27. Mai 2006 15:05 schrieb Juergen Spitzmueller:
> > I did that. Two things for a start:
> > - it would be good if --with-frontend=kde compiled the qt frontend
> > automatically.
>
> Why? It does not need it. Although the sources are shared, the object
> files are
Juergen Spitzmueller wrote:
.
>
> I'd second that.
>
Me too.
Cheers,
Charles
--
http://www.kde-france.org
> > automatically.
> >
> > Why? It does not need it. Although the sources are shared, the object
> > files are not.
>
> compiling --with-frontend=kde fails from a fresh tree for me, I needed
> --with-frontend="qt kde"
I forgot to change one include pa
Georg Baum wrote:
Am Samstag, 27. Mai 2006 15:11 schrieb Abdelrazak Younes:
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
Currently I simply implemented an additional frontend name kde. It is like
any other frontend, the only difference is
Georg Baum wrote:
I have created an experimental kde branch at
svn://svn.lyx.org/lyx/lyx-devel/branches/personal/baum/kde. It can be
configured in parallel to the other frontends. It is pretty lightweight (no
copied source files, therefore it has some ugly ifdefs). The only
difference to the
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
I did that. Two things for a start:
- it would be good if --with-frontend=kde compiled the qt frontend
automatically.
Yes and at runtime, the binary would switch to Qt only is KDE is not
Am Samstag, 27. Mai 2006 15:05 schrieb Juergen Spitzmueller:
I did that. Two things for a start:
- it would be good if --with-frontend=kde compiled the qt frontend
automatically.
Why? It does not need it. Although the sources are shared, the object
files are not.
- in the kfiledialog, the
Am Samstag, 27. Mai 2006 15:11 schrieb Abdelrazak Younes:
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
Currently I simply implemented an additional frontend name kde. It is like
any other frontend, the only difference is that the sources
Georg Baum wrote:
> I have created an experimental kde branch at
> svn://svn.lyx.org/lyx/lyx-devel/branches/personal/baum/kde. It can be
> configured in parallel to the other frontends. It is pretty lightweight (no
> copied source files, therefore it has some ugly ifdefs). The only
> difference to
Juergen Spitzmueller wrote:
I'd second that.
Me too but shouldn't be an automatic detection?
I did that. Two things for a start:
- it would be good if --with-frontend=kde compiled the qt frontend
automatically.
Yes and at runtime, the binary would switch to Qt only is KDE is not
Am Samstag, 27. Mai 2006 15:05 schrieb Juergen Spitzmueller:
> I did that. Two things for a start:
> - it would be good if --with-frontend=kde compiled the qt frontend
> automatically.
Why? It does not need it. Although the sources are shared, the object
files are not.
> - in the kfiledialog,
Am Samstag, 27. Mai 2006 15:11 schrieb Abdelrazak Younes:
> Juergen Spitzmueller wrote:
> >
> > I'd second that.
>
> Me too but shouldn't be an automatic detection?
Currently I simply implemented an additional frontend name kde. It is like
any other frontend, the only difference is that the
I have created an experimental kde branch at
svn://svn.lyx.org/lyx/lyx-devel/branches/personal/baum/kde. It can be
configured in parallel to the other frontends. It is pretty lightweight (no
copied source files, therefore it has some ugly ifdefs). The only
difference to the qt3 frontend so far is
I have created an experimental kde branch at
svn://svn.lyx.org/lyx/lyx-devel/branches/personal/baum/kde. It can be
configured in parallel to the other frontends. It is pretty lightweight (no
copied source files, therefore it has some ugly ifdefs). The only
difference to the qt3 frontend so far is
Yves == Yves Bastide [EMAIL PROTECTED] writes:
Yves About autoconf 2.50: I've prepared a patch with compatibility
Yves macros, but it needs to be cleaned up a bit.
Great!
JMarc
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Yves == Yves Bastide [EMAIL PROTECTED] writes:
|
| Yves About autoconf 2.50: I've prepared a patch with compatibility
| Yves macros, but it needs to be cleaned up a bit.
|
| Great!
One thing thoug... do we really want them?
For users
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars For users compiling the configure script delivered with LyX is
Lars used, developers should all use the same tools. _Or_ is this a
Lars patch/addon to autoconf 2.50 to make it backwards compatible
Lars with 2.13?
In the latest KDE
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars For users compiling the configure script delivered with LyX is
| Lars used, developers should all use the same tools. _Or_ is this a
| Lars patch/addon to autoconf 2.50 to make it
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I am sure it is possible, the question is if we want it.
Yes, if this means rewriting ugly code to make it more reasonable. I
do not know the specifics, however.
JMarc
do not really care about the kde frontend, but are we
sure nobody will miss it? Is kde 1.x really dead?
it doesn't compile and is incomplete. Unless someone volunteers to see it
through to completion, it is pointless having it in the codebase. kde 1.x
may not be dead yet, but the number
> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
Yves> About autoconf 2.50: I've prepared a patch with compatibility
Yves> macros, but it needs to be cleaned up a bit.
Great!
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
|
| Yves> About autoconf 2.50: I've prepared a patch with compatibility
| Yves> macros, but it needs to be cleaned up a bit.
|
| Great!
One thing thoug... do we really want them?
For
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> For users compiling the configure script delivered with LyX is
Lars> used, developers should all use the same tools. _Or_ is this a
Lars> patch/addon to autoconf 2.50 to make it backwards compatible
Lars> with 2.13?
In the
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> For users compiling the configure script delivered with LyX is
| Lars> used, developers should all use the same tools. _Or_ is this a
| Lars> patch/addon to autoconf 2.50
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I am sure it is possible, the question is if we want it.
Yes, if this means rewriting ugly code to make it more reasonable. I
do not know the specifics, however.
JMarc
0/05/27 11:12:27)
moz lyx-devel 109 automake --version
automake (GNU automake) 1.4
moz lyx-devel 110 autoconf --version
> Personnally I do not really care about the kde frontend, but are we
> sure nobody will miss it? Is kde 1.x really dead?
it doesn't compile and is incomplete. Unless
(as it's not the source of the
John bug)
Personnally I do not really care about the kde frontend, but are we
sure nobody will miss it? Is kde 1.x really dead?
JMarc
On Thu, Jun 07, 2001 at 04:38:01PM +0200, Jean-Marc Lasgouttes wrote:
John == John Levon [EMAIL PROTECTED] writes:
John --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii
John Content-Disposition: inline
John Things are worse than I thought. My previously reported bug with
update
autoconf to 2.50 yet.
JMarc
John> Please apply the attached patch (as it's not the source of the
John> bug)
Personnally I do not really care about the kde frontend, but are we
sure nobody will miss it? Is kde 1.x really dead?
JMarc
On Thu, Jun 07, 2001 at 04:38:01PM +0200, Jean-Marc Lasgouttes wrote:
> > "John" == John Levon <[EMAIL PROTECTED]> writes:
>
> John> --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii
> John> Content-Disposition: inline
>
> John> Things are worse than I thought. My previously
Things are worse than I thought. My previously reported bug with autogen.sh
and the broken library thing is /not/ due to the attached patch.
I currently can't build lyx as a result. Can someone please look into the problem ?
Am I the only one who gets the problem with autogen.sh ?
Please apply
Things are worse than I thought. My previously reported bug with autogen.sh
and the broken library thing is /not/ due to the attached patch.
I currently can't build lyx as a result. Can someone please look into the problem ?
Am I the only one who gets the problem with autogen.sh ?
Please apply
On Fri, 1 Jun 2001, John Levon wrote:
frontends/kde/ should be removed as it is unmaintained
and is likely to stay that way. What's best to do ?
You're abandoning it? What ever happened to the arguement that KDE1 would
be around for ages to come? Has KDE2/Qt2 proved so popular? Or are you
On Fri, 1 Jun 2001, John Levon wrote:
> frontends/kde/ should be removed as it is unmaintained
> and is likely to stay that way. What's best to do ?
You're abandoning it? What ever happened to the arguement that KDE1 would
be around for ages to come? Has KDE2/Qt2 proved so popular? Or are
this gets rid of the kde config gubbins etc.
cvs remove -f config/kde.m4
thanks
john
--
Please crack down on the Chinaman's friends and Hitler's commander.
Mother is the best bet and don't let Satan draw you too fast.
A boy has never wept ... nor dashed a thousand kim. Did you hear me?
this gets rid of the kde config gubbins etc.
cvs remove -f config/kde.m4
thanks
john
--
"Please crack down on the Chinaman's friends and Hitler's commander.
Mother is the best bet and don't let Satan draw you too fast.
A boy has never wept ... nor dashed a thousand kim. Did you hear me?"
frontends/kde/ should be removed as it is unmaintained
and is likely to stay that way. What's best to do ?
Perhaps it could be mvd directly in the repository to the
old lyx module or something, to avoid leaving all the
dead directories around ?
I'll supply a patch shortly to remove KDE stuff
frontends/kde/ should be removed as it is unmaintained
and is likely to stay that way. What's best to do ?
Perhaps it could be "mv"d directly in the repository to the
old "lyx" module or something, to avoid leaving all the
dead directories around ?
I'll supply a patch shortly to remove KDE
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars did this get applied?
Yes.
JMarc
On Thursday 01 March 2001 21:33, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Attached is a small patch to be applied to the HEAD branch of CVS. It
| re-enables compilation of the KDE frontend.
did this get applied?
Apparently so. At least I've just compiled kde
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> did this get applied?
Yes.
JMarc
On Thursday 01 March 2001 21:33, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Attached is a small patch to be applied to the HEAD branch of CVS. It
> | re-enables compilation of the KDE frontend.
>
> did this get applied?
Apparentl
Angus Leeming [EMAIL PROTECTED] writes:
| Attached is a small patch to be applied to the HEAD branch of CVS. It
| re-enables compilation of the KDE frontend.
did this get applied?
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a small patch to be applied to the HEAD branch of CVS. It
| re-enables compilation of the KDE frontend.
did this get applied?
Lgb
Attached is a small patch to be applied to the HEAD branch of CVS. It
re-enables compilation of the KDE frontend.
Angus
patch.diff.gz
Attached is a small patch to be applied to the HEAD branch of CVS. It
re-enables compilation of the KDE frontend.
Angus
patch.diff.gz
On 7 Dec 2000, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| also I personally would like to see a re-organisation of the lyxfunc code
| to be more organised, as I briefly mentioned earlier. This would also be a
| great oppportunity for me to learn some more advanced
On 7 Dec 2000, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | also I personally would like to see a re-organisation of the lyxfunc code
> | to be more organised, as I briefly mentioned earlier. This would also be a
> | great oppportunity for me to learn some more
On 4 Dec 2000, Jean-Marc Lasgouttes wrote:
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
[...]
Asger If you by infrastructure mean the model abstraction, yes, this
Asger will be easy. But once again, you basically just shove
Asger complexity into the front-ends: Each
John Levon [EMAIL PROTECTED] writes:
| also I personally would like to see a re-organisation of the lyxfunc code
| to be more organised, as I briefly mentioned earlier. This would also be a
| great oppportunity for me to learn some more advanced C++ ;)
Yes, please. If not for anything else than
On 4 Dec 2000, Jean-Marc Lasgouttes wrote:
> > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
[...]
> Asger> If you by infrastructure mean the model abstraction, yes, this
> Asger> will be easy. But once again, you basically just shove
> Asger> complexity into the front-ends:
John Levon <[EMAIL PROTECTED]> writes:
| also I personally would like to see a re-organisation of the lyxfunc code
| to be more organised, as I briefly mentioned earlier. This would also be a
| great oppportunity for me to learn some more advanced C++ ;)
Yes, please. If not for anything else
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger Therefore, I must retract the argument that GUII will make the
Asger model more basic, since obviously it isn't for the dialogs and
Asger the menus.
Thanks :)
Asger If you by infrastructure mean the model abstraction, yes,
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Therefore, I must retract the argument that GUII will make the
Asger> model more basic, since obviously it isn't for the dialogs and
Asger> the menus.
Thanks :)
Asger> If you by infrastructure mean the model
On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
Nope. We have several things the provide dynamic menus:
I'm glad that the menu model in LyX is more complete than I thought.
Congratulations on some good work there.
Therefore, I must retract the argument that GUII will make the model more
basic,
I'm not sure what we gain with that. The problems which exist in some
architectures (e.g. how do you update a dynamic menu when it is teared off)
will continue to exist anyway. If you find a good solution for a
frontend, I am sure it will work with the current scheme.
The only problem of
On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
> Nope. We have several things the provide dynamic menus:
I'm glad that the menu model in LyX is more complete than I thought.
Congratulations on some good work there.
Therefore, I must retract the argument that GUII will make the model more
basic,
> I'm not sure what we gain with that. The problems which exist in some
> architectures (e.g. how do you update a dynamic menu when it is teared off)
> will continue to exist anyway. If you find a good solution for a
> frontend, I am sure it will work with the current scheme.
The only problem
My advice is clear: Small steps. The first step is model/view separation
for one toolkit. Honestly, I doubt that you can handle even that
task. But please: Don't try to do the big one in one go, or you'll end up
with a new 1.1.x.
Well I can reassure you on that front. We plan to do
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger I knew you wouldn't do this, so I have to bring out some
Asger heavier ammo: The menus and toolbars. These, you are beginning
Asger to tackle, but you haven't quite yet.
The current communication model is broken, but the
"Jürgen" == Jürgen Vigna J writes:
Jürgen [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
"Matthias" == Matthias Ettrich [EMAIL PROTECTED] writes:
Hello there, I've been reading this thread when it was nearly over,
so all the technical points have been taken. Since I am not going
to do that
On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
Menus and toolbars are read at startup already. It would be better to
change them on the fly, but this should be doable.
I know the menus and toolbars exist as data structures (after all, we
started this together in Italy), and therefore, it's
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger In parenthesis, we should add that this has been accomplished
Asger by defining a minimum feature set: We cut out the dynamic part
Asger of the menus that existed previously (i.e. LinuxDoc adaption),
Asger and focused on a core
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I have been thinking of moving _all_ toolbar/menu stuff into the
Lars GUI and have _no_ backend support. This will allow the Tk to use
Lars whatever method/scheme it sees at the best for its implementaion
Lars of toolbars and menus.
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars I have been thinking of moving _all_ toolbar/menu stuff into the
| Lars GUI and have _no_ backend support. This will allow the Tk to use
| Lars whatever method/scheme it sees at
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I really think that this code has nothing to do in the
Lars "backend", imho it is part of the frontend, if it is directly in
Lars the tk code or in the common frontend code does not concern me
Lars as much.
You just mean that the
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| You just mean that the common code should not be named "backend"?
| Well, it's called MenuDesc right now, so it should be OK :)
With "backend" I mean the core LyX structures.
| Lars Let's imagine a lyx-server-only port. Why should the
| Lars
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Yes but we still have the toolbarbackend as a global variable.
It should probably be a member of LyXGUI or LyXView (I'm not clear
about what is the role of these different classes).
Lars Agree. And I belive that the location should
> My advice is clear: Small steps. The first step is model/view separation
> for one toolkit. Honestly, I doubt that you can handle even that
> task. But please: Don't try to do the big one in one go, or you'll end up
> with a new 1.1.x.
Well I can reassure you on that front. We plan to do
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I knew you wouldn't do this, so I have to bring out some
Asger> heavier ammo: The menus and toolbars. These, you are beginning
Asger> to tackle, but you haven't quite yet.
The current communication model is broken, but
> "Jürgen" == Jürgen Vigna writes:
Jürgen> [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>>
>>> "Matthias" == Matthias Ettrich <[EMAIL PROTECTED]> writes:
>> Hello there, I've been reading this thread when it was nearly over,
>> so all the technical points have been taken. Since I am not
On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
> Menus and toolbars are read at startup already. It would be better to
> change them on the fly, but this should be doable.
I know the menus and toolbars exist as data structures (after all, we
started this together in Italy), and therefore, it's
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> In parenthesis, we should add that this has been accomplished
Asger> by defining a minimum feature set: We cut out the dynamic part
Asger> of the menus that existed previously (i.e. LinuxDoc adaption),
Asger> and focused
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I have been thinking of moving _all_ toolbar/menu stuff into the
Lars> GUI and have _no_ backend support. This will allow the Tk to use
Lars> whatever method/scheme it sees at the best for its implementaion
Lars> of toolbars
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I have been thinking of moving _all_ toolbar/menu stuff into the
| Lars> GUI and have _no_ backend support. This will allow the Tk to use
| Lars> whatever method/scheme
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I really think that this code has nothing to do in the
Lars> "backend", imho it is part of the frontend, if it is directly in
Lars> the tk code or in the common frontend code does not concern me
Lars> as much.
You just mean
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| You just mean that the common code should not be named "backend"?
| Well, it's called MenuDesc right now, so it should be OK :)
With "backend" I mean the core LyX structures.
| Lars> Let's imagine a lyx-server-only port. Why should the
|
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Yes but we still have the toolbarbackend as a global variable.
It should probably be a member of LyXGUI or LyXView (I'm not clear
about what is the role of these different classes).
Lars> Agree. And I belive that the
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger Would you be still be enthusiastic to participate in LyX
Asger development if GUII was dropped and focus was on Qt as the main
Asger toolkit?
NO!
But I don't know what I would have said before reading Matthias'
messages :)
"Matthias" == Matthias Ettrich [EMAIL PROTECTED] writes:
Hello there,
I've been reading this thread when it was nearly over, so all the
technical points have been taken. Since I am not going to do that
again, I'll restrict myself to the subjective part :)
Matthias Of course. Restricting LyX
[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
"Matthias" == Matthias Ettrich [EMAIL PROTECTED] writes:
Hello there,
I've been reading this thread when it was nearly over, so all the
technical points have been taken. Since I am not going to do that
again, I'll restrict myself to the subjective
On Mon, Nov 27, 2000 at 05:29:20PM +0100, Jean-Marc Lasgouttes wrote:
"Matthias" == Matthias Ettrich [EMAIL PROTECTED] writes:
I've been reading this thread when it was nearly over, so all the
technical points have been taken. Since I am not going to do that
again, I'll restrict myself to
On 24 Nov 2000, Lars Gullik Bjønnes wrote:
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:
| You have to distuingish between GUII and model/view separation.
I really do not see the difference between mvs and guii when only one
toolkit is supported, except that with only one toolkit
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Would you be still be enthusiastic to participate in LyX
Asger> development if GUII was dropped and focus was on Qt as the main
Asger> toolkit?
NO!
But I don't know what I would have said before reading Matthias'
> "Matthias" == Matthias Ettrich <[EMAIL PROTECTED]> writes:
Hello there,
I've been reading this thread when it was nearly over, so all the
technical points have been taken. Since I am not going to do that
again, I'll restrict myself to the subjective part :)
Matthias> Of course.
[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>
>> "Matthias" == Matthias Ettrich <[EMAIL PROTECTED]> writes:
>Hello there,
>I've been reading this thread when it was nearly over, so all the
>technical points have been taken. Since I am not going to do that
>again, I'll restrict myself to the
1 - 100 of 184 matches
Mail list logo
