with spaces on unices, then? IIRC they tend to break
LaTeX runs anyway, so maybe we don't care either?
Cheers, Kuba Ober
What about filepaths with spaces on unices, then? IIRC they tend to break
LaTeX runs anyway, so maybe we don't care either?
Ahhh. But MikTeX on Windows definitely does support spaces in file names.
Moreover, since everything is copied to a temp directory for compilation
and the file names
never had any official Windows users to date.
What about filepaths with spaces on unices, then? IIRC they tend to break
LaTeX runs anyway, so maybe we don't care either?
Cheers, Kuba Ober
> > What about filepaths with spaces on unices, then? IIRC they tend to break
> > LaTeX runs anyway, so maybe we don't care either?
>
> Ahhh. But MikTeX on Windows definitely does support spaces in file names.
> Moreover, since everything is copied to a temp directory for compilation
> and the
? This precludes any plugins etc. Is
that what we really want?
Most those errors are simple superfluous export/import definitions, removing
them will cure the errors.
Cheers, Kuba Ober
tatic Qt at all? This precludes any plugins etc. Is
that what we really want?
Most those errors are simple superfluous export/import definitions, removing
them will cure the errors.
Cheers, Kuba Ober
I rather think it is the user interface parts that need work in
such a case. The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back and forth doing modifications in two places. :-)
Makes sense.
Kuba
On wtorek 18 stycze 2005 08:49 am, Andreas Vox wrote:
Kuba Ober [EMAIL PROTECTED] writes:
I rather think it is the user interface parts that need work in
such a case. The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back
> I rather think it is the user interface parts that need work in
> such a case. The core shouldn't really see the difference between
> two users updating one document, or one user moving
> rapidly back and forth doing modifications in two places. :-)
Makes sense.
Kuba
On wtorek 18 styczeÅ 2005 08:49 am, Andreas Vox wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> > > I rather think it is the user interface parts that need work in
> > > such a case. The core shouldn't really see the difference between
> > > two users updat
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a
| server-client-architecture for LyX that works in the same way as the
| team modus of starcraft. One opens a server with the document to edit
| and other people
> | I think we could have saved some time, if we were able to work both on a
> | single document at the same time. So I propose a
> | server-client-architecture for LyX that works in the same way as the
> | "team modus" of starcraft. One opens a server with the document to edit
> | and other
Have you looked at the page?
http://www.lyx.org/donations.php
Please tell if it is something in particular that needs to change.
and meetings -- heh you should have just said out in the open that
developers do need beer every once in a while :)
Cheers, Kuba
everyday
makes you :)
Cheers, Kuba Ober
> Have you looked at the page?
>
> http://www.lyx.org/donations.php
>
> Please tell if it is something in particular that needs to change.
"and meetings" -- heh you should have just said out in the open that
developers do need beer every once in a while :)
Cheers, Kuba
s what sleeping 5-6 hours a day everyday
makes you :)
Cheers, Kuba Ober
I have no idea if Windows shortcuts can be accomodated easily, it would
be great if at least the Qt file browser could handle them. Any ideas?
IIRC if you don't get too fancy the Qt file browser simply launches a standard
windows dialog box which IIRC handles shortcuts fine? As long as it
> I have no idea if Windows shortcuts can be accomodated easily, it would
> be great if at least the Qt file browser could handle them. Any ideas?
IIRC if you don't get too fancy the Qt file browser simply launches a standard
windows dialog box which IIRC handles shortcuts fine? As long as it
for more than 10 years the latex world is waiting for a
parser, which works ...
TeX? I presume that the safest, if not very lightweight way would be to use
TeX itself.
Reimplementing crux of TeX as far as macro processing goes isn't that hard if
one has TeXbook handy, but if one could just
On roda 22 grudzie 2004 05:45 pm, Herbert Voss wrote:
Kuba Ober wrote:
for more than 10 years the latex world is waiting for a
parser, which works ...
TeX? I presume that the safest, if not very lightweight way would be to
use TeX itself.
Reimplementing crux of TeX as far as macro
> for more than 10 years the latex world is waiting for a
> parser, which works ...
TeX? I presume that the safest, if not very lightweight way would be to use
TeX itself.
Reimplementing crux of TeX as far as macro processing goes isn't that hard if
one has TeXbook handy, but if one could just
On Åroda 22 grudzieÅ 2004 05:45 pm, Herbert Voss wrote:
> Kuba Ober wrote:
> >>for more than 10 years the latex world is waiting for a
> >>parser, which works ...
> >
> > TeX? I presume that the safest, if not very lightweight way would be to
> > use TeX its
On pitek 17 grudzie 2004 02:42 am, Georg Baum wrote:
Kuba Ober wrote:
I vaguely recall this idea being raised at one point or another, but
can't the temporary file names be simply generated from some kind of a
unique global counter, maybe merged with PID?
We have a global counter
Different idea: (almost) drop support for cygwin!
Here is an idea I had while reading your message: we could also decide
that the cygwin version of LyX is a posix-like one, and that it can
only deal with unix-paths. This means that most special cygwin code
will go away, and that LyX/Cygwin
paths, if the beginning matches
/[a-zA-Z]: the first slash is dropped, and if the beginning matches
/[^:/]+ then the first slash is replaced with \\
Cheers, Kuba Ober
On pitek 17 grudzie 2004 10:14 am, Kuba Ober wrote:
I think we should probably use only internal_path and only work inside
LyX with paths which use / as separator. Of course, a second problem
is that win32 names will retain drive numbers, but stuff in filetools
should take care
On pitek 17 grudzie 2004 10:16 am, Jean-Marc Lasgouttes wrote:
Kuba == Kuba Ober [EMAIL PROTECTED] writes:
I think we should probably use only internal_path and only work
inside LyX with paths which use / as separator. Of course, a second
problem is that win32 names will retain drive
On piÄtek 17 grudzieÅ 2004 02:42 am, Georg Baum wrote:
> Kuba Ober wrote:
> > I vaguely recall this idea being raised at one point or another, but
> > can't the temporary file names be simply generated from some kind of a
> > unique global counter, maybe merged with PID?
> Different idea: (almost) drop support for cygwin!
>
> Here is an idea I had while reading your message: we could also decide
> that the cygwin version of LyX is a posix-like one, and that it can
> only deal with unix-paths. This means that most special cygwin code
> will go away, and that
k to Windows paths, if the beginning matches
"/[a-zA-Z]:" the first slash is dropped, and if the beginning matches
"/[^:/]+" then the first slash is replaced with \\
Cheers, Kuba Ober
On piÄtek 17 grudzieÅ 2004 10:14 am, Kuba Ober wrote:
> > I think we should probably use only internal_path and only work inside
> > LyX with paths which use / as separator. Of course, a second problem
> > is that win32 names will retain drive numbers, but stuff in filetools
&g
On piÄtek 17 grudzieÅ 2004 10:16 am, Jean-Marc Lasgouttes wrote:
> >>>>> "Kuba" == Kuba Ober <[EMAIL PROTECTED]> writes:
> >>
> >> I think we should probably use only internal_path and only work
> >> inside LyX with paths which use /
on?
That would preclude any need for mangling.
But I presume there must be some other reason for mangling? I'm just trying to
understand.
Cheers, Kuba Ober
40_.tmp, ..., 16940_000a.tmp and so on?
That would preclude any need for mangling.
But I presume there must be some other reason for mangling? I'm just trying to
understand.
Cheers, Kuba Ober
On pitek 10 grudzie 2004 01:49 pm, Andre Poenitz wrote:
On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote:
Is this ok [self-explaining patch attached], or are there some kind of
moral reasons for not showing half a cursor?
I am not sure we are allowed to show the lower part
On piÄtek 10 grudzieÅ 2004 01:49 pm, Andre Poenitz wrote:
> On Mon, Dec 06, 2004 at 08:53:25PM +0100, Alfredo Braunstein wrote:
> > Is this ok [self-explaining patch attached], or are there some kind of
> > moral reasons for not showing half a cursor?
>
> I am not sure we are allowed to show the
And all those extra member functions could just as well be separate
functions.
It seems that even the std::string is now considered too fat. Most of
what it does is possible to implement outside of the class.
So I am not argueing against functions that operate on strings. I am
argueing
> And all those extra member functions could just as well be separate
> functions.
>
> It seems that even the std::string is now considered too fat. Most of
> what it does is possible to implement outside of the class.
>
> So I am not argueing against functions that operate on strings. I am
>
implementation. Afaik std::string doesn't have
from8BitLocal(), fromUcs(), etc.
Cheers, Kuba Ober
the amount of meat
that's missing in 4.0tp2
Did they even specify any hard deadlines?
Cheers, Kuba Ober
On czwartek 09 grudzie 2004 10:42 am, Lars Gullik Bjnnes wrote:
Kuba Ober [EMAIL PROTECTED] writes:
Are you sure of this. I know that the std::string in libstdc++ has
gotten quite a bit of performance tweaks lately.
(gcc 3.4.x and 4.x)
|
| So they finally play catch up with Qt. Nice
ul string implementation. Afaik std::string doesn't have
from8BitLocal(), fromUcs(), etc.
Cheers, Kuba Ober
ir containers, and
not strewn across everywhere.
> And I actually
> wonder how Trolltech will meet its 4.0 deadline given the amount of meat
> that's missing in 4.0tp2
Did they even specify any hard deadlines?
Cheers, Kuba Ober
On czwartek 09 grudzieÅ 2004 10:42 am, Lars Gullik BjÃnnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> >> Are you sure of this. I know that the std::string in libstdc++ has
> >> gotten quite a bit of performance tweaks lately.
> >> (gcc 3.4.x and 4.x)
&
$ rpm -qf /usr/share/aclocal/libtool.m4
libtool-1.5.6-4
$ rpm -qf '*.m4'
Either do
rpm -qf *.m4
without quotes, or
rpm -qf `locate .m4`
rpm -qf always needs a real file to query, not a wildcard.
Cheers, Kuba Ober
> $ rpm -qf /usr/share/aclocal/libtool.m4
> libtool-1.5.6-4
>
> $ rpm -qf '*.m4'
Either do
rpm -qf *.m4
without quotes, or
rpm -qf `locate .m4`
rpm -qf always needs a real file to query, not a wildcard.
Cheers, Kuba Ober
enough. Is that normal?
No, it's essentially bad design. Unfortunately, many big commercial apps
suffer from it as well.
Cheers, Kuba Ober
execute events fast enough. Is that normal?
No, it's essentially bad design. Unfortunately, many big commercial apps
suffer from it as well.
Cheers, Kuba Ober
operator= should destroy whatever resources should be destroyed, etc.
The code with explicit destructor call and placement new is more efficient of
course, but less intuitive.
Cheers, Kuba Ober
>
> >*this = SomeClass(foo);
Maybe operator= should destroy whatever resources should be destroyed, etc.
The code with explicit destructor call and placement new is more efficient of
course, but less intuitive.
Cheers, Kuba Ober
in most cases, otherwise they are to be reimplemented in
specializations
I.e. there's nothing wrong with virtual interface methods, as long as they are
used in the correct sense.
Here derived class = specialization.
Cheers, Kuba Ober
common sense in most cases, otherwise they are to be reimplemented in
specializations
I.e. there's nothing wrong with virtual interface methods, as long as they are
used in the correct sense.
Here derived class = specialization.
Cheers, Kuba Ober
chauvinist am I :)
Cheers, Kuba Ober
> with...
ROTFL :) I.e. what a male chauvinist am I :)
Cheers, Kuba Ober
On pitek 24 wrzesie 2004 06:20 am, Angus Leeming wrote:
Specifically, the section:
Does LyX have support for non-English speakers/writers/readers?
At least Polish language support works :)
Cheers, Kuba
On pitek 24 wrzesie 2004 09:04 am, Angus Leeming wrote:
Kuba Ober wrote:
On pi?tek 24 wrzesie? 2004 06:20 am, Angus Leeming wrote:
Specifically, the section:
Does LyX have support for non-English speakers/writers/readers?
At least Polish language support works :)
Which bits
work,
they... just work :)
Cheers, Kuba Ober
On piÄtek 24 wrzesieÅ 2004 06:20 am, Angus Leeming wrote:
> Specifically, the section:
>
> Does LyX have support for non-English speakers/writers/readers?
At least Polish language support works :)
Cheers, Kuba
On piÄtek 24 wrzesieÅ 2004 09:04 am, Angus Leeming wrote:
> Kuba Ober wrote:
> > On pi?tek 24 wrzesie? 2004 06:20 am, Angus Leeming wrote:
> >> Specifically, the section:
> >>
> >> Does LyX have support for non-English speakers/writers/readers?
> >
cument language".
That's about all that I have to say on the subject, I admit. When things work,
they... just work :)
Cheers, Kuba Ober
On czwartek 23 wrzesie 2004 05:17 am, Ruurd Reitsma wrote:
Actually, someone already made an installer for Win32. Just havent had the
time to do anything with it...
I volunteer to make one with NSIS, if need be.
Cheers, Kuba Ober
On czwartek 23 wrzesieÅ 2004 05:17 am, Ruurd Reitsma wrote:
> Actually, someone already made an installer for Win32. Just havenÂt had the
> time to do anything with it...
I volunteer to make one with NSIS, if need be.
Cheers, Kuba Ober
, for whatever buggy reason.
Disclaimer: my experience with OSX is rather sparse at this point.
Cheers, Kuba Ober
mselves that they expose a OSX
bug that shows only in app-bunded fonts, for whatever buggy reason.
Disclaimer: my experience with OSX is rather sparse at this point.
Cheers, Kuba Ober
broken output, i.e. emits minus operators instead of
medium dashes.
Cheers, Kuba Ober
instead.
> This tex file was created by running html2latex on the output from "groff
> -Thtml".
Then html2latex creates broken output, i.e. emits minus operators instead of
medium dashes.
Cheers, Kuba Ober
format is that of: making the parser unmanageable, some poor soul
untangling the parser, and then making the format easier to parse so that
said sould wouldn't be so poor in the future, with such cycle repeated often
over the years :)
Cheers, Kuba Ober
On poniedziaek 23 sierpie 2004 02:29 pm, Asger Kunuk Ottar Alstrup wrote:
On Thu, 19 Aug 2004, Andre Poenitz wrote:
PS: For some reason I sorely missed Asger this year.
I have absolutely no clue why you would bring that up in such a
discussion.
Regards,
Asger
(who seems to try to make an
current lyx format is that of: making the parser unmanageable, some poor soul
untangling the parser, and then making the format easier to parse so that
said sould wouldn't be so poor in the future, with such cycle repeated often
over the years :)
Cheers, Kuba Ober
On poniedziaÅek 23 sierpieÅ 2004 02:29 pm, Asger Kunuk Ottar Alstrup wrote:
> On Thu, 19 Aug 2004, Andre Poenitz wrote:
> > PS: For some reason I sorely missed Asger this year.
>
> I have absolutely no clue why you would bring that up in such a
> discussion.
>
> Regards,
> Asger
(who seems to try
.
Cheers, Kuba Ober
evel of make.
Cheers, Kuba Ober
as we're looking for a package.
It should work fine on any redhat version and sure does on both fedoras.
As a fallback (if rpm -qf returns an error) I'd also do
rpm -qa | grep ^[^-]*qt[^-]*-[0-9]
Cheers, Kuba Ober
of archive failed on file /usr/bin/lyx;41178d7e:
cpio: open
failed - Permission denied
Probably there's something else wrong.
Cheers, Kuba Ober
,
non-packaged Qt, but that's not an issue here as we're looking for a package.
It should work fine on any redhat version and sure does on both fedoras.
As a fallback (if rpm -qf returns an error) I'd also do
rpm -qa | grep "^[^-]*qt[^-]*-[0-9]"
Cheers, Kuba Ober
## [100%]
> error: unpacking of archive failed on file /usr/bin/lyx;41178d7e:
> cpio: open
> failed - Permission denied
Probably there's something else wrong.
Cheers, Kuba Ober
On poniedziaek 05 lipiec 2004 07:27 am, Andre Poenitz wrote:
On Mon, Jul 05, 2004 at 12:09:10PM +0100, Jose' Matos wrote:
On Monday 05 July 2004 11:00, Jean-Marc Lasgouttes wrote:
I will probably be able to bring one if really needed, but I have no
idea about german electric outlets...
On czwartek 08 lipiec 2004 01:35 pm, Georg Baum wrote:
Am Donnerstag, 8. Juli 2004 16:44 schrieb Kuba Ober:
Well, the German system is IIRC called Shuco, from the name of the
company that probably sold the system outlets and plugs first. It has
two
Sorry, but I can't resist to nitpick
On poniedziaÅek 05 lipiec 2004 07:27 am, Andre Poenitz wrote:
> On Mon, Jul 05, 2004 at 12:09:10PM +0100, Jose' Matos wrote:
> > On Monday 05 July 2004 11:00, Jean-Marc Lasgouttes wrote:
> > > I will probably be able to bring one if really needed, but I have no
> > > idea about german electric
On czwartek 08 lipiec 2004 01:35 pm, Georg Baum wrote:
> Am Donnerstag, 8. Juli 2004 16:44 schrieb Kuba Ober:
> > Well, the German system is IIRC called Shuco, from the name of the
> > company that probably sold the "system" outlets and plugs first. It has
> > tw
On poniedziaek 05 lipiec 2004 07:32 pm, Christian Ridderstrm wrote:
Hi
I came across this article:
http://www-106.ibm.com/developerworks/linux/library/l-distcc.html?ca=dgr-l
nxw01distccTips
that discusses using somethign called 'distcc' to speed up compilations.
Basically you run a
On poniedziaÅek 05 lipiec 2004 07:32 pm, Christian RidderstrÃm wrote:
> Hi
>
> I came across this article:
>
> http://www-106.ibm.com/developerworks/linux/library/l-distcc.html?ca=dgr-l
>nxw01distccTips
>
> that discusses using somethign called 'distcc' to speed up compilations.
>
>
On roda 30 czerwiec 2004 02:49 pm, Dieter Jurzitza wrote:
As I readily mentioned, nothing wrong is occuring with normal typing. But
if I try to view one of the docs - crash.
This happens for my selfcompiled version (1.3.4) in the same way as for the
precompiled (1.3.0) (= linked to the wrong
On Åroda 30 czerwiec 2004 02:49 pm, Dieter Jurzitza wrote:
> As I readily mentioned, nothing wrong is occuring with "normal" typing. But
> if I try to view one of the docs -> crash.
> This happens for my selfcompiled version (1.3.4) in the same way as for the
> precompiled (1.3.0) (= linked to
Hi,
An idea came to my mind so I feel compelled to share :)
Wouldn't it be nifty to hack the wiki enough to allow it to work on lyx files?
That way we could have wiki-ed lyx user's manual -- I don't think there are
any projects out there that allow online updating of the manuals. Since lyx
Hi,
An idea came to my mind so I feel compelled to share :)
Wouldn't it be nifty to hack the wiki enough to allow it to work on lyx files?
That way we could have wiki-ed lyx user's manual -- I don't think there are
any projects out there that allow online updating of the manuals. Since lyx
On Friday 07 May 2004 09:46 am, John Levon wrote:
On Fri, May 07, 2004 at 03:02:26PM +0200, Apache wrote:
Recent wiki posts:
(http://wiki.lyx.org/pmwiki.php/Main/AllRecentChanges)
* http://wiki.lyx.org/pmwiki.php/LyX/Welcome - 14:07 7/05 by
* http://wiki.lyx.org/pmwiki.php/LyX/LyX
Should be restored, unless this or another kid resumes his/her activity.
Cheers, Kuba
On Friday 07 May 2004 09:46 am, John Levon wrote:
> On Fri, May 07, 2004 at 03:02:26PM +0200, Apache wrote:
> > Recent wiki posts:
> > (http://wiki.lyx.org/pmwiki.php/Main/AllRecentChanges)
> >
> > * http://wiki.lyx.org/pmwiki.php/LyX/Welcome - 14:07 7/05 by
> > *
Should be restored, unless this or another kid resumes his/her activity.
Cheers, Kuba
On Wednesday 28 April 2004 06:00 pm, Lars Gullik Bjønnes wrote:
Kuba Ober [EMAIL PROTECTED] writes:
| My kadu user id is 3323343, you can download the client below
|
| http://kadu.net/index.php?page=downloadlang=en
Kadu what the F*** is kadu?
Like AIM, and has a nice english translation
On Wednesday 28 April 2004 02:07 am, Asger Kunuk Ottar Alstrup wrote:
I probably have to miss this year's meeting, now that Elias is in the
picture. He will be older next year, and I've never been to Poland, so
that sounds more realistic for me.
There are direct flights from Copenhagen to
On Wednesday 28 April 2004 06:00 pm, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> | My kadu user id is 3323343, you can download the client below
> |
> | http://kadu.net/index.php?page=download=en
>
> Kadu what the F*** is kadu?
Like AIM
On Wednesday 28 April 2004 02:07 am, Asger Kunuk Ottar Alstrup wrote:
> I probably have to miss this year's meeting, now that Elias is in the
> picture. He will be older next year, and I've never been to Poland, so
> that sounds more realistic for me.
There are direct flights from Copenhagen to
On Tuesday 27 April 2004 12:45 pm, Alfredo Braunstein wrote:
Kuba Ober wrote:
This is all highly unofficial and can be considered hearsay:
It'd be doable in Pozna, Poland. What'd ya think?
Cheers, Kuba Ober
Cheers indeed!
Super methinks.
Okay, now the old and tiring bureaucracy: I
My kadu user id is 3323343, you can download the client below
http://kadu.net/index.php?page=downloadlang=en
(No, I'm not using AIM or anything of the sort)
Cheers, Kuba Ober
Okay, now the old and tiring bureaucracy: I need to make a nice letter to
the head of the institute, describing what the conference is about and so
on. Yada yada that it's opensource and so on. If those who have attended
the previous conferences could give some input about what's the usual
stuff, Guiness other imports would be
obviously more) :)
- social events - from zero to a hero (no idea)
Cheers, Kuba Ober
My kadu user id is 3323343, you can download the client below
http://kadu.net/index.php?page=downloadlang=en
(No, I'm not using AIM or anything of the sort)
Cheers, Kuba Ober
On Tuesday 27 April 2004 12:45 pm, Alfredo Braunstein wrote:
> Kuba Ober wrote:
> > This is all highly unofficial and can be considered hearsay:
> >
> > It'd be doable in PoznaÅ, Poland. What'd ya think?
> >
> > Cheers, Kuba Ober
>
> Cheers indeed!
>
>
1 - 100 of 493 matches
Mail list logo
