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
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 kde-c
> "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 a
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 o
> "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?
Geor
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 that
> 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
Juergen Spitzmueller wrote:
.
>
> I'd second that.
>
Me too.
Cheers,
Charles
--
http://www.kde-france.org
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 no
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 sou
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, t
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
detected
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
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 t
6 2000/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. Unle
> "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
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> 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 lat
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 us
> "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
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 repo
not 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
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
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 "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 stuf
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
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> did this get applied?
Yes.
JMarc
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
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 advan
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 tha
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:
> "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
> 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, si
> "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
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> 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 th
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
> "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 an
> "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
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| But it only demonstrates what Matthias already said: We are closer to
| the lowest common standard, rather than closer to the possible
| standard.
| For instance, there is no functionality to handle dynamic menus, in the
| sense of menus t
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 rela
> "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 g
> "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
> 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 no
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 t
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
[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
> "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. Restrictin
> "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'
messag
On Thu, Nov 23, 2000 at 02:52:35PM +1000, Allan Rae wrote:
>
> Fast, flexible development comes from a stable source base not from
[...]
...and well-written, well-commented source. Let's not forget that.
> Forking a KLyX, a GLyX and a CursesLyX won't make it quicker and easier to
> develop LyX
On Thu, Nov 23, 2000 at 02:52:35PM +1000, Allan Rae wrote:
>
>
> P.S. I've spent so much time writing this that I'm inclinded to just
> include it word for word in the next issue of LDN rather than just link to
> to it. Do you have a problem with me doing that? Do you want your quotes
> remov
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| Let me repeat in this context, what I just wrote to Allan:
|
| You have to distuingish between GUII and model/view separation.
|
| You achieve the long-time stability, and avoidance of "death of
| entropy" with basic model/view separatio
On Thu, 23 Nov 2000, Asger K. Alstrup Nielsen wrote:
> On Thu, 23 Nov 2000, Allan Rae wrote:
>
> Dear Allan,
>
> Let me try to summarize some of your points:
>
> 1) Being independent is better, since you'll potentially last longer in
>a changing environment
> 2) Different GUI frontends cr
[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>Therefore it is relevant informally to ask all the developers:
>Would you be still be enthusiastic to participate in LyX development if
>GUII was dropped and focus was on Qt as the main toolkit?
Well my answer is: NO! (I love short mails ;)
Jür
[EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>
>I've kept everybody waiting long enough...
>It's a long reply... really long but then you wouldn't believe I wrote it
>if it was short. I think I covered everything.
You got me and I really expected something like this from you (and I thought Asge
[EMAIL PROTECTED] wrote:
>
> At this point, LyX development is less need-driven than ever.
> The developers also do not do the work because they want more
> respect of users. The existing users crowd is already enthuisiatic,
> and it does not matter whether there are 100,000 users or
> 1,
On Thursday 23 November 2000 12:35, Asger K. Alstrup Nielsen wrote:
> Indirectly, you acknowledge that Matthias is right about one thing:
>
> GUII takes a long time.
>
> The basic question then remains: Is GUII worth it?
>
> Please distinguish between GUII and model/view separation. These thin
On Thu, 23 Nov 2000, Asger K. Alstrup Nielsen wrote:
> Would you be still be enthusiastic to participate in LyX development if
> GUII was dropped and focus was on Qt as the main toolkit?
>
> Greets,
>
> Asger
It seems to me that the implemented framework is a reasonable method for
providing ex
On Wed, 22 Nov 2000, Martin Vermeer wrote:
> As one who is actually more concerned with this user focus than with the
> code, I still have to say that I can understand it. I can see that
> writing excellent code is laying the basis for developing an excellent
> application. That's why I very much
On Thu, 23 Nov 2000, Allan Rae wrote:
Dear Allan,
Let me try to summarize some of your points:
1) Being independent is better, since you'll potentially last longer in
a changing environment
2) Different GUI frontends creates competition, and thus more innovation
3) Different frontends attra
On 22 Nov 2000, Lars Gullik Bjønnes wrote:
> - the NEW_INSET code that you mentioned. (lot still missing,
> itemize/enumerate is still hardcoded, insetfloat needs some work ...)
> - the restructureing of internal storage formats (from implicit home
> grown linked list to std::containers) And
I've kept everybody waiting long enough...
It's a long reply... really long but then you wouldn't believe I wrote it
if it was short. I think I covered everything.
Glossary.
GUII = GUI Independence.
On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> >
> > Because the current GUI-I code is limited
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Technology Committee of AGU. I hope to be able to work on getting LaTeX
| more accepted within the AGU community (it is already, but people
| complain the lack of easy visual tools ;-), and especially to make the
| AGU LaTeX classes as augmented by Pa
On Wed, Nov 22, 2000 at 01:18:19PM +0100, Asger K. Alstrup Nielsen wrote:
...
> I think I can answer some of it for you:
>
> Some developers are not mainly interested in bringing a modern
> application to the users. It's more fun to play around with a
> code, learn C++ some more, clean u
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| I was never angry about the KDE port you did. I even considered branching
| with you.
I was never angry about the _port_, I was angry about the lack of
communication!
| Now, the situation is different. I think it is more realistic to sw
On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> Maybe you'll change mind and will be able to convince Lars and Asger :)
I was never angry about the KDE port you did. I even considered branching
with you.
The only reason that I didn't jump aboard that branch was that the other
LyX developers wou
Hi, Matthias.
I've been reading this discussion with interest. As one of the guys doing
this coding, I feel it has some relevance to me!!
The only point I don't understand is why you believe the GUI-Independence
stuff is limiting? The LyX kernel knows nothing about the GUI. It just emits
a fe
> According to the latest surveys, the vast majority of linux users has
> machines with more than 300 Mhz and at least 64MB ram.
My personal survey gives an 486DX2-66/16 MB (and LyX 0.10 ;-)), and a
P133/48MB at home where I do most of my writing and at work a P100/64, a
P133/32, a PII350/512 an
Friday 17 November 2000 21:11 wrote John Levon:
> On Fri, 17 Nov 2000, Matthias Ettrich wrote:
[snip]
> True, but then you lose the KDE2 added bonuses. I'm sure *you* are aware
> of that :)
>
> I'm not averse to a pure-Qt port, but personally I'm not interested in
> it ...
In KDE2, pure Qt and KD
On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> Note that I didn't do anything with this code for months. Just sending a
> short note "we wrote something, do something with it or leave it", isn't
> sufficient. It was clear to me that I will have to spend some time arguing
> with you people at l
Friday 17 November 2000 18:06 wrote John Levon:
> On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> > sorry for not sending this email ealier. Mandrake is innocent
>
> OK
>
> > During the KOffice Meeting after the Linux Tag two months ago,
> > [...]
> > Unfortunatly, neither he nor me had the time to
On Fri, 17 Nov 2000, Matthias Ettrich wrote:
> sorry for not sending this email ealier. Mandrake is innocent
OK
> During the KOffice Meeting after the Linux Tag two months ago,
> [...]
> Unfortunatly, neither he nor me had the time to finish the things we planned.
> Too many things happened w
Lars,
I send this to you as I'm not on qt-devel. Can you please forward it to the
appropriate mailing list?
Thanks.
Matthias
> -- Forwarded Message --
> Subject: Re: Mandrake and KDe frontend
> Date: 16 Nov 2000 21:17:59 +0100
> From: [EMAIL PROTEC
On Thu, 16 Nov 2000, Andre Poenitz wrote:
>
> I just started browsing through the 'frontends' directory (I have not been
> there for ages)...
>
> I find it a bit surprising that the 'new's and 'delete's are a bit out of
> balance. Is there some black magic in the backgraound that releases the
>
I just started browsing through the 'frontends' directory (I have not been
there for ages)...
I find it a bit surprising that the 'new's and 'delete's are a bit out of
balance. Is there some black magic in the backgraound that releases the
resources allocated in RefDlg::RefDlg(...) for instance?
On Thu, 21 Sep 2000, Paul Seelig wrote:
> I just hope that the GTK/GNOME frontend becomes a worthwhile compile
> ASAP.
afaik the gnome frontend is currently more advanced than the KDE one !
> I'd really love to get rid of having to use LyX via the XForms
> frontend once and for all... ;-)
>
On Thu, Sep 21, 2000 at 03:06:52PM +0100, John Levon wrote:
> On Thu, 21 Sep 2000, Paul Seelig wrote:
>
> > Isn't it a futile effort still using qt-1.4x and KDE-1.x for the KLyX
> > port? Wouldn't it make more sense basing this port right away on a
> > GPL'ed qt-2.x and the forthcoming KDE-2.x?
On Thu, 21 Sep 2000, Angus Leeming wrote:
> The linker doesn't require the .la files at all. This is something to do with
> libtool.
OK, so is it correct to insist that libkdecore.la exists ? Can anyone
comment ?
> Everything makes perfectly too, with no tweaking of src/Makefile when I link
> > You'll see that it has decided to use the installed kde libraries rather
> > than the ones I want! Uses the correct header files though!
>
> I am guessing that you do not have a libkdecore.la file in the specified
> location. Is this correct ? I must admit personally I don't understand the
> r
No, I don't think so. The changes that would need to be made to the code base
are minimal and well documented. Porting apps from kde-1.1.2 to kde-2.x is
(apparently) very easy. Anyway, the guy doing the port (John Levon) is
running kde-1.1.2, so really the question is academic. Feel free to
co
On Thu, 21 Sep 2000, Paul Seelig wrote:
> Hi Angus!
>
> It's great to hear about your success! :-)
>
> On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote:
> > checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
> > headers /usr/users/aleem/OTHERS_CODE/qt-1.44/incl
Hi Angus!
It's great to hear about your success! :-)
On Thu, Sep 21, 2000 at 02:20:09PM +0100, Angus Leeming wrote:
> checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
> headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
[ snip ]
> checking for K
On Thu, 21 Sep 2000, Angus Leeming wrote:
> * Recreate configure by running autogen.sh
> * Run configure through the shell script that I sent before. Also attached to
> this mail.
>
> Here I get:
> checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
> headers /usr/users/alee
* Recreate configure by running autogen.sh
* Run configure through the shell script that I sent before. Also attached to
this mail.
Here I get:
checking for Qt... libraries /usr/users/aleem/OTHERS_CODE/qt-1.44/lib,
headers /usr/users/aleem/OTHERS_CODE/qt-1.44/include
On Thu, 21 Sep 2000, Angus Leeming wrote:
> When it came to configuring/compiling/linking lyx, again all went fairly
> smoothly, but there are some bugs in the configure script which could be
> removed.
>
I have just done :
./configure --with-frontend=kde --with-qt-dir=/usr/lib/qt-1.45/
and
On Thu, 21 Sep 2000, Angus Leeming wrote:
> Ok, I'm feeling pretty proud of myself. I've compiled and linked lyx with
> the kde frontend.
cool !
> Finally, the src/Makefile defines the qt and kdelibraries as:
> -lqt -lkdecore
> This results in lots of "
Ok, I'm feeling pretty proud of myself. I've compiled and linked lyx with
the kde frontend. This has meant compiling the kde-1.1.2 libraries with DEC
cxx; straightforward, but tedious with all those "using std::xxx" and extern
"C" calls I've come to know an
On 19-Sep-2000 Angus Leeming wrote:
> The small patch attached to this mail enables error and warning free
> compilation of the kde frontend using DEC cxx. Patch made against today's
> (19Sep) CVS.
Applied!
The small patch attached to this mail enables error and warning free
compilation of the kde frontend using DEC cxx. Patch made against today's
(19Sep) CVS.
Angus
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-
to compile
> (and maybe even link??) but the resulting executable will not have these
> dialogs. Seems a bit pointless, no?
>
> If, of course, you wish to write the missing dialogs...
>
> Angus
>
The attached small patch allows to compile kde frontend. The resulting
executab
Marko> current CVS does not compile with KDE frontend due to the difference in
Marko> Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs
Marko> class constructor expects LyXView* as its argument in Xforms frontend
Marko> (src/frontends/Dialogs.h src/frontends/xfor
current CVS does not compile with KDE frontend due to the difference in
Dialogs class definition for KDE and Xforms frontends. Namely, Dialogs
class constructor expects LyXView* as its argument in Xforms frontend
(src/frontends/Dialogs.h src/frontends/xforms/Dialogs.C) and LyXFunc* as
an
95 matches
Mail list logo
