> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Hi, Attached updates the progress of the GTK port on guii.php3.
I applied it.
JMarc
On Thu, 29 Mar 2001, Allan Rae wrote:
> Still tripping down memory lane...
>
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port to
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Suggested/rejected GUII implementation number two. Both of the above
> > cases just end up being yet another restrictive cross-platform toolkit.
> > We don't need that. If you want one of those then just create a port to
> > the cross-platform toolki
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port to
> the cross-platform toolkit of your choice and use that.
Oh, I did not sugge
Wow a trip down memory lane...
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Kalle> What could be done would be something like this:
> >
> > #ifdef XFORMS
> > typedef FL_OBJECT* WidgetPtr;
> > #elif defined QT
> > typedef QWidget* WidgetPtr;
> > #endif
>
> This should get encapsul
On Thursday 29 March 2001 14:28, Edwin Leuven wrote:
> It seems to me that having 5 implementations in one file separated by
> #ifndef's is not a good idea. I'd rather see 5 different implementation
> files. Not only will the code be cleaner, but I also like the idea of
> having the xform code in
> Kalle> What could be done would be something like this:
>
> #ifdef XFORMS
> typedef FL_OBJECT* WidgetPtr;
> #elif defined QT
> typedef QWidget* WidgetPtr;
> #endif
This should get encapsulated in a real class, say "Widget", with different
implementaions for Qt, xforms, etc.
> K
It seems to me that having 5 implementations in one file separated by
#ifndef's is not a good idea. I'd rather see 5 different implementation
files. Not only will the code be cleaner, but I also like the idea of having
the xform code in the xform dir, the qt code in the qt dir, etc.
Although n
On Thu, 27 Jul 2000, Angus Leeming wrote:
> JMarc> Several problems in cvs: Makefile.am has not been updated with the new
> JMarc> files, form_url.[Ch] have not been added. I am not sure whether I can
> JMarc> safely run make updatesrc to have the files. Angus?
>
> Ahhh! Awake and on the ball as
JMarc> Several problems in cvs: Makefile.am has not been updated with the new
JMarc> files, form_url.[Ch] have not been added. I am not sure whether I can
JMarc> safely run make updatesrc to have the files. Angus?
Ahhh! Awake and on the ball as usual, Jean-Marc!
A general point about "make updat
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Angus Leeming <[EMAIL PROTECTED]> writes: | Lars, | | I see
Lars> that you've added my patch. Thanks. | It looks however, as if
Lars> you haven't updated Makefile.am in | src/frontends/xforms. The
Lars> patch below does that. |
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Also fdfix.sh does not have correct execute permissions. Does
| Lars> cvs | preserve them?
|
| Lars> Only if se
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Also fdfix.sh does not have correct execute permissions. Does
Lars> cvs | preserve them?
Lars> Only if set from the begginging.
So, should makefile invoke is as "${SHEL
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Also fdfix.sh does not have correct execute permissions. Does cvs
| preserve them?
Only if set from the begginging.
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars,
|
| I see that you've added my patch. Thanks.
| It looks however, as if you haven't updated Makefile.am in
| src/frontends/xforms. The patch below does that.
|
| In addition, you should
|
| cd src/frontends/xforms/forms
| make updatesrc
| mv f
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Attached is a patch porting InsetUrl to GUI-independence. It
Angus> also uses the InsetCommandParams class that I have mentioned
Angus> before.
Several problems in cvs: Makefile.am has not been updated with the new
files, form_url
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars> | As well as a diff file, the attachment contains some new files:
| Lars> | src/frontends/xforms/FormUrl.h
| Lars> | src/frontends/xforms/FormUrl.C
| Lars> | src/frontends/xforms/forms/form_url.fd
|
| Lars> you can run diff with
Lars> | As well as a diff file, the attachment contains some new files:
Lars> | src/frontends/xforms/FormUrl.h
Lars> | src/frontends/xforms/FormUrl.C
Lars> | src/frontends/xforms/forms/form_url.fd
Lars> you can run diff with -N you know... to get the new files.
We've had
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a patch porting InsetUrl to GUI-independence. It also uses the
| InsetCommandParams class that I have mentioned before.
|
| As well as a diff file, the attachment contains some new files:
| src/frontends/xforms/FormUrl.h
| src/f
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bj&resh;nnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> |
> | If you want, I can do the changes (and also do the changes I suggested
> | for layout.C)
>
> Nooo! :-)
>
> I absolutely disagree with you ad. the parsing of layout files.
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
| [Rewrite the loading parsing logic]
| > If you want, I can do the changes (and also do the changes I suggested
| > for layout.C)
|
| When you volunteer, obviously it's a good idea to make the change.
| You won't find me arguing against tha
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
| > > Dekel> However, the real problem lies on parsing .lyx files at
| > > Dekel> Buffer::readLyXformat2 which is done using if-else statements
| > > Dekel> (... else if (token == "\
[Rewrite the loading parsing logic]
> If you want, I can do the changes (and also do the changes I suggested
> for layout.C)
When you volunteer, obviously it's a good idea to make the change.
You won't find me arguing against that ;-)
I'm sure the patch would be welcomed.
Maybe it's time for De
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote:
> > Dekel> However, the real problem lies on parsing .lyx files at
> > Dekel> Buffer::readLyXformat2 which is done using if-else statements
> > Dekel> (... else if (token == "\\emph") ... ) This is very
> > Dekel> inefficien
> Dekel> However, the real problem lies on parsing .lyx files at
> Dekel> Buffer::readLyXformat2 which is done using if-else statements
> Dekel> (... else if (token == "\\emph") ... ) This is very
> Dekel> inefficient!
>
> Yes, this code should use LyxLex correctly.
Actually, this is not a real
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> Perhaps because the standard C++ library dioes not have hashed
| Lars> containers? (that is an sgi extension (among others))
|
| Lars> As for faster search times, these tables are som small that I
| Lars> don't think it would have made a d
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> However, the real problem lies on parsing .lyx files at
Dekel> Buffer::readLyXformat2 which is done using if-else statements
Dekel> (... else if (token == "\\emph") ... ) This is very
Dekel> inefficient!
Yes, this code should use Lyx
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bj&resh;nnes wrote:
> | > Lars> Or we can just sort it... this will slow things down a tiny bit,
> | > Lars> but you will never be able you measure that. (manually)
> | >
> | > With an assertion, we are always sure that manual sorting will be
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 28, 2000
Lars> at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | > >
Lars> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | > | >
Lars> Lars> Or we can just s
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Or we can just sort it... this will slow things down a tiny bit,
| > Lars> but you will never be able y
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bj&resh;nnes <[EMAIL PROTECTED]> writes:
>
> Lars> Or we can just sort it... this will slow things down a tiny bit,
> Lars> but you will never be able you measure that. (manually)
>
> With an asse
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Or we can just sort it... this will slow things down a tiny bit,
Lars> but you will never be able you measure that. (manually)
With an assertion, we are always sure that manual sorting will be
done. This is linear time, and on
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
|
| Asger> The LyXLex creature requires a list of keywords to function.
| Asger> This is a simple list of tokens, but it only works if it is
| Asger> sorted. Real life has show
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> The LyXLex creature requires a list of keywords to function.
Asger> This is a simple list of tokens, but it only works if it is
Asger> sorted. Real life has shown that this is hard. Last time, it
Asger> was Juergen who co
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > is at easy if it can possibly get. But maybe you are right and XTL is
|
| Read:
|
| ..is as easy as it ...
|
| I think I'll have another beer to get sober...
Not, in Norway yet are you?
Lgb
On Fri, 25 Feb 2000, Andre Poenitz wrote:
> > We have considered extending the string interface
> > with various ways of encoding the information, but that would require
> > slow and error-prone parsing of strings.
>
> I don't agree. Sorry... (Erm... well, it's friday, isn't it)
>
> String pa
> True. But a lot of trouble can be saved by using things like yacc...
Yacc is complex and error-prone.
It adds comparably much complexity to things. Also, Yacc by itself
does not cut it. You have to bring in the smaller cousin Lex, or Bison
if you are so inclined.
However, that complicates
> is at easy if it can possibly get. But maybe you are right and XTL is
Read:
..is as easy as it ...
I think I'll have another beer to get sober...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
> You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
> If we use XTL, there will be less debugging than if we have to write
> our own parser. Just take a look at any pars
André argues that we should not use XTL because we can do things with
a string. He thinks that the added complexity of another library is
not worth the hassle -- after all a text format is well-known, and
if it is well encapsulated, it's no problem.
Surprise!
This is exactly what XTL is: A wel
> The string interface is too simple for the kind of information that should
> be passed around.
What kind of information can not be passed around as strings?
> We have considered extending the string interface
> with various ways of encoding the information, but that would require
> slow and e
[XTL]
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
> Btw XDR is a platform independent format for binary representation. I use
> XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with
> some automat
> On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> > The best format is the raw format, since it's minimalistic and the
> > fastest. We don't need interoperability with external sources, so
> > the raw format is the best solution.
>
> That was what I thought the plain text was. The versio
John I've answered your original post at the end.
On Tue, 22 Feb 2000, Roland Krause wrote:
> After that, someone will probably have to make a real concept for
> LyXFunc, i.e. events from the document view, menu, toolbar, and GUI
> initialization as well as other things that I dont understand ye
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote:
> The best format is the raw format, since it's minimalistic and the
> fastest. We don't need interoperability with external sources, so
> the raw format is the best solution.
That was what I thought the plain text was. The version I currentl
On Wed, 23 Feb 2000, Roland Krause wrote:
> I did that too and I admit I dont get what this is suposed to do for LyX? Do
> you intend to have a new file format?
No. A better way to shift data between the various components of LyX
(internal or external).
> Btw XDR is a platform independent form
Hi,
On Tue, 22 Feb 2000, Allan Rae wrote:
> On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote:
>
> I've looked at the code and read the manual for it a couple of times on
> the bus. So I agree it's exactly what we need.
I did that too and I admit I dont get what this is suposed to do for LyX
> I am intending to make XTL a part of the rae branch sometime this week as
> I want to try it out communication with LyXFunc. I'll have to get the
> latest release to see what's new. The version I have exports to plain
> text but doesn't import from it. It seems very fast for CORBA and XDF(?)
On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote:
> Hi!
Hello Asger!
> I've used it for a few things and can only say that it rocks your
> socks off. I think this is exactly what we need for the communication
> layer in the GUI indep-work. It's clean, fast, and very elegant
> if you ask me
Hi John,
GUI independece is coming, there is light at the end of the tunnel. Platform
independence is a long way to go.
Alan Rae does the coordination of some of the GUI independence work in a
seperate branch (rae-2). He was able to implement signal/slot for the Dialogs
and move one Dialog into it
"Dr. Ing. Roland Krause" <[EMAIL PROTECTED]> writes:
| Grep is your friend but so is any other cross-referencer.
|
| Isnt there an etags goal in the makefiles?
make TAGS
Lgb
Hi Allan,
I wanted to answer earlier, just didnt get to it.
I 've seen that you checked in some stuff for the big GUI independence
hack, good. Let's see that I can scrap some time to help with this now.
First, you were correct, that I hadn't read all about the LyXfunc discussion
in the mailing
On 28 Jan 2000, Jean-Marc Lasgouttes wrote:
> > "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes:
>
> Duncan> Do not hold your breath, since I need to get a PhD, but it
> Duncan> occurs to me that GUI independence would be accelerated by
> Duncan> having some common cases as re-usable w
> "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes:
Duncan> Do not hold your breath, since I need to get a PhD, but it
Duncan> occurs to me that GUI independence would be accelerated by
Duncan> having some common cases as re-usable widgets or something
Duncan> spiritually similar. How ma
54 matches
Mail list logo
