On Wed, Sep 13, 2006 at 07:23:55PM -0500, Bo Peng wrote:
> >I'm wondering if it does not pick the wrong moc. On Debian, moc is called
> >moc-qt4
>
> Why is it so? Is there a moc-qt3?
Yes and a symlink "moc" managed via update-alternatives pointing to the
current Debian default.
Yes sometimes Debi
On Thu, Sep 14, 2006 at 02:14:26AM +0200, Lars Gullik Bjønnes wrote:
>
> This patch removes the support for the latexaccent inset, in favour of
> unicode chars (combining or not.)
>
> I need some further help with the python part: revert is completely
> missing, I don't translate the "stroke" var
I'm wondering if it does not pick the wrong moc. On Debian, moc is called
moc-qt4
Why is it so? Is there a moc-qt3?
Bo
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| This patch removes the support for the latexaccent inset, in favour of
| unicode chars (combining or not.)
|
| I need some further help with the python part: revert is completely
| missing, I don't translate the "stroke" variants, and singular
| d
This patch removes the support for the latexaccent inset, in favour of
unicode chars (combining or not.)
I need some further help with the python part: revert is completely
missing, I don't translate the "stroke" variants, and singular
dot-less-i, dot-less-j. ...and do anyone remember what this "
With your patch, it compiles but stops with the qt4 frontend :
scons frontend=qt4 qt_dir=/usr/share/qt4 qt_lib_path=/usr/lib/qt4 -j3 lyx
g++ -o
debug/common/frontends/qt4/Action.o -c -g -O -DHAVE_CONFIG_H
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB
-Idebug
On Wed, Sep 13, 2006 at 11:05:32PM +0200, Georg Baum wrote:
> The attached version prints this:
>
> global has std::codecvt facet: 0
> global has std::ctype facet: 0
> global has std::num_put facet: 0
> newlocale has std::codecvt facet: 0
> newlocale has std::ctype facet: 1
> newlocale has std::n
On Wed, Sep 13, 2006 at 09:57:58PM +0200, Andre Poenitz wrote:
> On Wed, Sep 13, 2006 at 06:08:24PM +0200, Enrico Forestieri wrote:
> > ATM Qt4 is not officially available for cygwin but eventually it will be:
> > http://thread.gmane.org/gmane.comp.kde.devel.cygwin/3191/focus=3191
> >
> > This one
Georg Baum schrieb:
The installation directory does not mean anything in this case. What
clean_dvi fixes are included graphics with spaces in the name, e.g. from
the command
\includegraphics{"test file"}
Thanks, I'll do some tests to get closer to the problem.
Me neither, but it does a usef
Am Mittwoch, 13. September 2006 21:36 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Am Mittwoch, 13. September 2006 20:50 schrieb Lars Gullik Bjønnes:
> | > Georg Baum <[EMAIL PROTECTED]> writes:
> | > | Index: src/support/types.h
> | > | =
Am Mittwoch, 13. September 2006 22:37 schrieb Angus Leeming:
> Georg Baum <[EMAIL PROTECTED]> writes:
> > Try this one. On linux the output is:
> >
> > global has std::codecvt facet: 0
> > global has std::ctype facet: 0
> > global has std::num_put facet: 0
> > terminate called after throwing an in
On Wed, Sep 13, 2006 at 12:47:31PM +0200, Peter Kümmel wrote:
> > Jean-Marc Lasgouttes wrote:
> >> I definitely do not want to release a version of lyx which is unusable
> >> by a large portion of our user base.
>
> Am I right, that this is your main argument?
> When we could be sure that everywh
On Wed, Sep 13, 2006 at 07:44:25PM +0200, Michael Gerz wrote:
> Hello,
>
> in analogy to the character/text styles for normal text, I would like to
> shift math text styles to the "edit=>math" submenu.
>
> In order to do so, LFUN_MATH_INSERT must be disabled in regular text
> mode (otherwise, t
On Mon, Sep 11, 2006 at 08:57:13AM +0200, Georg Baum wrote:
> Lars Gullik Bjønnes wrote:
>
> > You should probably do operator+= as well. But I am not sure if that
> > is possible as a out-of-class operator.
>
> It is not, otherwise I would have done it. We can of course make docstring a
> subcla
On Sun, Sep 10, 2006 at 10:28:37PM +0200, Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Am Sonntag, 10. September 2006 21:25 schrieb Abdelrazak Younes:
> | > Let's do this cleanup in the next round then.
> |
> | That is not possible if you use my bformat version.
> |
On Wed, Sep 13, 2006 at 12:22:41PM +0200, Charles de Miramon wrote:
> Jean-Marc Lasgouttes wrote:
> > I definitely do not want to release a version of lyx which is unusable
> > by a large portion of our user base. If we are qt4 only, we have to do
> > what is needed to get people to use it. There i
On Wed, Sep 13, 2006 at 11:20:23AM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Probably so... but one additional reason for dropping xforms
> Martin> was undoubtedly that it wasn't up to the same standard any
> Martin> more, and fal
On Wed, Sep 13, 2006 at 04:17:15PM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> | > | Am I right that all of the filetools.h API should be converted to
> | > docstring?
> | >
On Tue, Sep 12, 2006 at 03:54:40PM +0100, John Levon wrote:
> On Tue, Sep 12, 2006 at 04:38:20PM +0200, Abdelrazak Younes wrote:
>
> > >| You've just described my very plan ;-). I just thought it was obvious
> > >| so I didn't care to write it so explicitly. The problem is just that
> > >| Lars wo
On Sun, Sep 10, 2006 at 11:17:02PM +0200, Lars Gullik Bjønnes wrote:
> Michael Gerz <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes schrieb:
> | > I don't want one man that is unwilling to work on qt3 decide what
> | > happens with it. Get consensus, then let's ditch it. Not before.
> | >
>
On Tue, Sep 12, 2006 at 10:17:07AM +, Angus Leeming wrote:
> Read his mails again (snippets below). I don't see nothing that says "NO!"
The problem is that anything that's not a clear 'yes' turns up as
'no' in somebodies internal counting.
So being politically correct and state that it's not
On Mon, Sep 11, 2006 at 11:50:31AM +0100, Ozgur Ugras BARAN wrote:
> It is so rare that, It is fantastic not to be wrong. :))
>
> then it should work well for the case \command[][]{}
>
> any comments on backporting this feature to lyx 1.4.x ?? it shouldn't
> take too much time for me..
Have it
On Tue, Sep 12, 2006 at 02:43:05PM +0200, Lars Gullik Bjønnes wrote:
> Very right. If the bus thing happens after step 1, we are left with no
> spellchecker.
I would be very surprised if you weren't able to reverse a patch in svn.
Andre'
On Wed, Sep 13, 2006 at 06:08:24PM +0200, Enrico Forestieri wrote:
> ATM Qt4 is not officially available for cygwin but eventually it will be:
> http://thread.gmane.org/gmane.comp.kde.devel.cygwin/3191/focus=3191
>
> This one will be an X11 version. The last month, quite scared by the "drop
> qt3
On Mon, Sep 11, 2006 at 09:19:14AM +0100, Ozgur Ugras BARAN wrote:
> Therefore the command and its parameters are isolated from anything else,
> including another {}. Am I wrong?? (probably I am :) )
Erm. No. I was probably thinking about tex2lyx or such.
Should be pretty safe given this explan
On Sun, Sep 10, 2006 at 10:58:19PM +0200, Lars Gullik Bjønnes wrote:
> Michael Gerz <[EMAIL PROTECTED]> writes:
>
> | Georg Baum schrieb:
> | > Am Sonntag, 10. September 2006 21:25 schrieb Abdelrazak Younes:
> | >
> | >> Let's do this cleanup in the next round then.
> | >>
> | > That is not possib
On Tue, Sep 12, 2006 at 01:19:57PM +0200, Leuven, E. wrote:
> it seems that there is a consensus to end the support of qt3,
> so let's do that starting from now.
>
> i suggest that for the time being qt3 is treated as gtk.
I even want to see that on clean checkouts and leving it in limbo will
re
On Tue, Sep 12, 2006 at 08:19:27AM +0100, Ozgur Ugras BARAN wrote:
> Well, the Akademy did not held, yet, therefore the release date of
> KDE4 did not announced. But my guess is it will be around Sept. 2007
> as earliest. Therefore, many distros that releases yearly or twice
> yearly will be releas
On Mon, Sep 11, 2006 at 08:18:40PM +0100, John Levon wrote:
> On Mon, Sep 11, 2006 at 09:10:08PM +0200, Michael Gerz wrote:
>
> > Decide on your own what that means for Qt3...
>
> One small note: if qt3 dies (and the development cost does seem quite
> onerous), then the first 1.5.0 release should
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
> I am tempted to convert everything even when a std::string would
> suffice. For example getFormatFromContents(), should that be:
>
> lyx::docstring const getFormatFromContents(lyx::docstring const & name);
>
> or
>
> std::stri
On Tue, Sep 12, 2006 at 11:10:40AM +0200, Abdelrazak Younes wrote:
> >Personally, I'm sold on the "qt3 is redundant" argument. If it's a hassle,
> >kill it. However, I also buy into JMarc's complaints that there has been
> >too much noise from the "cry wolf" brigade. The strength of your argument
On Tue, Sep 12, 2006 at 11:10:04AM +0200, Helge Hafting wrote:
> Now that is a solution too, of course. If you volunteer to maintain
> the qt3 frontend, then everybody else can work mainly with qt4
> while you port the changes. That's the best of both worlds - faster/easier
> development and stil
On Wed, Sep 13, 2006 at 09:51:33PM +0200, Georg Baum wrote:
> Am Mittwoch, 13. September 2006 18:24 schrieb Enrico Forestieri:
> > I have installed STLport and the above program still says "size: 2", so
> > I think that it "has to be" that way on windows.
>
> Well, the STL can't change the size of
Georg Baum <[EMAIL PROTECTED]> writes:
> Try this one. On linux the output is:
>
> global has std::codecvt facet: 0
> global has std::ctype facet: 0
> global has std::num_put facet: 0
> terminate called after throwing an instance of 'std::bad_cast'
> what(): St8bad_cast
H. So it throws whe
On Wednesday 13 September 2006 21:28, Rainer Dorsch wrote:
> Most likely not a lyx issue at all.
Glad to help.
Glad to know. :-)
> Thanks,
> Rainer
--
José Abílio
Thanks for your help.
I found the problem now, the textclass line was missing. I looks like somebody
removed it manually from the lyx file. I will ask my colleague (towards which
cvs points;-) tomorrow what happend.
Most likely not a lyx issue at all.
Thanks,
Rainer
Am Mittwoch, 13. September
Georg Baum wrote:
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
Angus Leeming wrote:
Note that keeping std::string for the format name will enable you to
enforce
the distinction at compile time. Even clearer if you follow Georg's
suggestion
of
typedef std::string lyx:
Am Mittwoch, 13. September 2006 18:24 schrieb Enrico Forestieri:
> I have installed STLport and the above program still says "size: 2", so
> I think that it "has to be" that way on windows.
Well, the STL can't change the size of builtin types, so that is expected.
wchar_t does not "have to be" 2
On Wednesday 13 September 2006 20:22, Rainer Dorsch wrote:
> Hmm...I don't find lyx2lyx:
>
> mclin:s1 # ls /opt/lyx-1.4.2/bin/
> lyx lyxclient tex2lyx
> mclin:s1 #
>
> I must miss something...
No you don't. :-)
We don't ship lyx2lyx as binary since usually it is not needed an lyx knows
whe
On Wednesday 13 September 2006 20:19, Rainer Dorsch wrote:
> [EMAIL PROTECTED]:~> python -V
> Python 2.2.1
> [EMAIL PROTECTED]:~>
>
> Does not look bad (?)
Nope it is fine. :-)
I found the reference to this in http://docs.python.org/lib/typesseq.html
(1)
When s is a string or Unicode string ob
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Mittwoch, 13. September 2006 20:50 schrieb Lars Gullik Bjønnes:
| > Georg Baum <[EMAIL PROTECTED]> writes:
| > | Index: src/support/types.h
| > | ===
| > | --- src/support/types.h (Revisio
Am Mittwoch, 13. September 2006 20:50 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
> | Index: src/support/types.h
> | ===
> | --- src/support/types.h (Revision 14987)
> | +++ src/support/types.h (Arbeit
Am Mittwoch, 13. September 2006 20:04 schrieb José Matos:
> On Wednesday 13 September 2006 15:56, Rainer Dorsch wrote:
> > Hello,
> >
> > I installed lyx 1.4.2 and got many lyx 1.3 files converted, but one is
> > failing. How can I debug that? Can I call lyx2lyx from the command line
> > and get mo
Am Mittwoch, 13. September 2006 19:57 schrieb José Matos:
> On Wednesday 13 September 2006 15:07, Rainer Dorsch wrote:
> > LyX comes up after that, but I get an error reported:
> >
> > Checking whether TeX allows spaces in file names...
> > Traceback (most recent call last):
> > File
> > "/afs/b
Georg Baum <[EMAIL PROTECTED]> writes:
| AC_CHECK_SIZEOF does this for us.
|
| Shall I put this in?
Yes· (minor thingie below)
| Index: src/support/types.h
| ===
| --- src/support/types.h (Revision 14987)
| +++ src/support/t
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
> Angus Leeming wrote:
> > Note that keeping std::string for the format name will enable you to
enforce
> > the distinction at compile time. Even clearer if you follow Georg's
suggestion
> > of
> > typedef std::string lyx::asc
On Wednesday 13 September 2006 15:56, Rainer Dorsch wrote:
> Hello,
>
> I installed lyx 1.4.2 and got many lyx 1.3 files converted, but one is
> failing. How can I debug that? Can I call lyx2lyx from the command line and
> get more verbose error messages.
Yes on both accounts. :-)
call lyx2lyx
On Wednesday 13 September 2006 15:07, Rainer Dorsch wrote:
> LyX comes up after that, but I get an error reported:
>
> Checking whether TeX allows spaces in file names...
> Traceback (most recent call last):
> File
> "/afs/bb/data/d3197/galaxy2/zLinux/lyx-1.4.2/share/lyx/configure.py", line
> 70
Hello,
in analogy to the character/text styles for normal text, I would like to
shift math text styles to the "edit=>math" submenu.
In order to do so, LFUN_MATH_INSERT must be disabled in regular text
mode (otherwise, the math submenu is shown all the time).
Could you please have a look at
Am Mittwoch, 13. September 2006 18:17 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Index: src/support/docstring.h
> | ===
> | --- src/support/docstring.h (Revision 14982)
> | +++ src/support/docstring.h
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
No, all is as it should be. NTFS uses UTF-16 (thanks again, Joost), so that
can be stored reasonably well in std::wstring although there will be corner
cases where two wchar_ts are required to represent a single unicode charac
Bo Peng wrote:
>> I need to investigate this problem more.
>
> Can you compile the following .c code without libiconv installed, by
> using glibc or something else?
>
> #include
> #include
> int main() {
> iconv_t cd = iconv_open("","");
> iconv(cd,NULL,NULL,NULL,NULL);
> iconv_clo
Abdel, I get this warning:
../../../../src/frontends/qt4/QLToolbar.h: In
constructor 'lyx::frontend::QLToolbar::QLToolbar(const
ToolbarBackend::Toolbar&, lyx::frontend::GuiView&)':
../../../../src/frontends/qt4/QLToolbar.h:81:
warning: 'lyx::frontend::QLToolbar::owner_' will be initialized afte
On 9/13/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> I need to investigate this problem more.
Could you please test the attached patch? I have added a check for
iconv function, without those libs.
Index: development/scons/SConstruct
=
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > | > I'd prefere is most of this work tried to leverage boost::filesystem
> > | > as much as possible.
> > |
> > | Yes, I think I've read somewhere that boost::filesystem will support
> > | the default encoding of the system in 1.34.
> >
> > Note t
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
orrh I am not stupid!
I mean ascii is a subset of ucs4 using the first byte...
I need to investigate this problem more.
Can you compile the following .c code without libiconv installed, by
using glibc or something else?
#include
#include
int main() {
iconv_t cd = iconv_open("","");
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);
}
You can modify the code, add
On Wed, Sep 13, 2006 at 04:07:12PM +0200, Rainer Dorsch wrote:
> LyX comes up after that, but I get an error reported:
>
> Checking whether TeX allows spaces in file names...
> Traceback (most recent call last):
> File "/afs/bb/data/d3197/galaxy2/zLinux/lyx-1.4.2/share/lyx/configure.py",
> li
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Am I right that all of the filetools.h API should be converted to
| > docstring?
| > | | I have started the conversion already so please t
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
--
Lgb
On Wed, Sep 13, 2006 at 05:51:50PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > I am not sure what you mean but the following
> >
> > #include
> > #include
> >
> > int main()
> > {
> > printf("size: %d\n", sizeof(wchar_t));
> > return 0;
> > }
> >
> > prints "size: 2" on
Georg Baum <[EMAIL PROTECTED]> writes:
| Index: src/support/types.h
| ===
| --- src/support/types.h (Revision 14982)
| +++ src/support/types.h (Arbeitskopie)
| @@ -18,20 +18,10 @@
|
| #include "docstring.h"
|
| -#incl
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Perhaps we should go that way anyway. If the underlying systems can
| > support what we want (32bit char_types) then we use that, else we have
| > to use our own solution.
|
| I dug out the patch. It will use wchar_t if i
On Wed, Sep 13, 2006 at 05:01:12PM +0200, Georg Baum wrote:
> Abdelrazak Younes wrote:
>
> > But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
> > problem, wouldn't it? Enrico, would you comment on that?
>
> Does gcc 4 support wchar_t on mingw and cygwin? I ask because gcc 3.
On Wed, Sep 13, 2006 at 02:53:43PM +, Angus Leeming wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
> > problem, wouldn't it? Enrico, would you comment on that?
>
> Not really, because most people will grab the
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Maybe we should eliminate hardcoded boost::uint32_t except in
Georg> docstring.h even if we don't use wchar_t. What do others think?
Yes, I think we should do that. Most of the code has no business
knowing what lyx::char_type really i
On Wed, Sep 13, 2006 at 04:32:47PM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >Angus Leeming wrote:
> >
> >>Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> >>>We have of course one other options:
> >>>
> >>>On linux: char_type is wchar_t
> >>>docstring is wstring
> >>>
> >>>On
Enrico Forestieri wrote:
> I am not sure what you mean but the following
>
> #include
> #include
>
> int main()
> {
> printf("size: %d\n", sizeof(wchar_t));
> return 0;
> }
>
> prints "size: 2" on both MinGW and Cygwin.
Sorry, I have read so much about this issue that I mixed things
Angus Leeming wrote:
Abdelrazak Younes writes:
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs
resulting from this misunderstanding.
format names are
On Wed, Sep 13, 2006 at 04:23:36PM +0200, Georg Baum wrote:
> Angus Leeming wrote:
>
> > Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> >> We have of course one other options:
> >>
> >> On linux: char_type is wchar_t
> >> docstring is wstring
> >>
> >> On windows: char_type is uint32_
On 9/13/06, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Of course I could provide support for aspell, ispell, Enchant and the
controller reorg in one big patch.
Another option seems to be to write patches 1,2,3 and 4. Once the have
all been written, commit them all seperately, but on the same
Abdelrazak Younes writes:
> Georg Baum wrote:
> > Abdelrazak Younes wrote:
>>> Then we need docstring as we don't know which kind of extension a user
>>> could create.
>> Please: format name != file extension!!! I fixed several bugs
>> resulting from this misunderstanding.
>> format names are uniq
> I have on my system /usr/local/lib/libiconv.so ...
You have downloaded and installed manually libiconv. Is it necessary ?
I am not 100% sure. If libc or someone else provides iconv() function,
then I should not have required it in scons
I need to investigate this problem more.
Bo
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Angus Leeming wrote:
Abdelrazak Younes ...> writes:
But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
problem, wouldn't it? Enrico, would you comment on that?
Not really, because most people will grab t
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Sure... I meant f
Lars Gullik Bjønnes wrote:
> Perhaps we should go that way anyway. If the underlying systems can
> support what we want (32bit char_types) then we use that, else we have
> to use our own solution.
I dug out the patch. It will use wchar_t if it is a 32bit type.
Maybe we should eliminate hardcoded
Georg Baum wrote:
Abdelrazak Younes wrote:
But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
problem, wouldn't it? Enrico, would you comment on that?
Does gcc 4 support wchar_t on mingw and cygwin?
I think I've read gcc 4.1 is compilable out of the box within both so
y
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Angus Leeming wrote:
>> Abdelrazak Younes ...> writes:
>>> But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
>>> problem, wouldn't it? Enrico, would you comment on that?
>> Not really, because most people will grab the official
Jean-Marc Lasgouttes schrieb:
I think I am even less willing to have 'bold' in the toolbar than in
the menus... Sorry.
It is because "bold" is bad and you want to make it as difficult as
possible to use it? In that case, I would like to propose to banish all
keybord short-cuts for "bold" as
Abdelrazak Younes wrote:
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
But I've seen ports of Gcc-4 to mingw and cygwin. That would solve
the problem, wouldn't it? Enrico, would you comment on that?
Not really, because most people will grab the official Qt4 from the
Trol
Abdelrazak Younes wrote:
> Then we need docstring as we don't know which kind of extension a user
> could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Georg
On Wed, Sep 13, 2006 at 03:37:30PM +0200, Helge Hafting wrote:
> John Levon wrote:
> >On Tue, Sep 12, 2006 at 10:11:31PM +0200, Helge Hafting wrote:
> >
> >
> >>It isn't a model - it is how this computer stuff actually happen on a
> >>low level.
> >>
> >
> >Precisely the problem.
> >
> Wel
Helge Hafting schrieb:
Cut and paste is surely better done with:
* keyboard only, or -
* mouse only - mark the text then drag the selection off somewhere.
But it must be in the menus too, because there is no standard
cut & paste keys on keyboards. Apps do this differently.
There is also no stand
Georg Baum writes:
> Uwe Stöhr wrote:
>> That means you will fix directly the programs dt2dv and dv2dt?
> I did not mean it like that. Anybody could do that with a decent set of test
> files (one file per problematic construct), but if you prepare such a set
> of test files then I can have a look
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
problem, wouldn't it? Enrico, would you comment on that?
Not really, because most people will grab the official Qt4 from the Trolls and
Well, on windows
Lars Gullik Bjønnes schrieb:
I know that we had some discussions about this, I belive one of the
arguments was: "Character Styles are misleading, it is not style on
single chars but on words and pieces of text."
But I can also apply the style to a single character.
Michael
Abdelrazak Younes wrote:
> But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
> problem, wouldn't it? Enrico, would you comment on that?
Does gcc 4 support wchar_t on mingw and cygwin? I ask because gcc 3.3 (and
probably earlier) have usable wchar_t support on linux, so this i
Georg Baum wrote:
Abdelrazak Younes wrote:
So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
Me neither but probably not. Unless a Chinese user for example use a
format is not defined in AS
Hello,
I installed lyx 1.4.2 and got many lyx 1.3 files converted, but one is
failing. How can I debug that? Can I call lyx2lyx from the command line and
get more verbose error messages.
Many thanks,
Rainer
--
Rainer Dorsch
Alzentalstr. 28
D-71083 Herrenberg
07032-919495
jabber: [EMAIL PROTECT
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> But I've seen ports of Gcc-4 to mingw and cygwin. That would solve the
> problem, wouldn't it? Enrico, would you comment on that?
Not really, because most people will grab the official Qt4 from the Trolls and
the you'll start hitting the classic AB
Uwe Stöhr wrote:
> Georg Baum schrieb:
>
>> It would probably not be difficult to fix that, the code is simple. In
>> fact, it will probbaly be less work to do that than to rip out all
>> appareances of clean_dvi from LyX and the installer.
>
> That means you will fix directly the programs dt2dv
Joost Verburg wrote:
> Originally, all Unicode Windows features and the NTFS file system
> used UCS-2 encoding. After Unicode 3.0 became available this has
> been upgraded. Windows 2000 and later support UTF-16.
Thanks, Joost.
Angus
Abdelrazak Younes wrote:
> So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
If the answer to that question is yes and it does not create problems
elsewhere, then it would be OK with me.
> In thi
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Asger" == Asger Ottar Alstrup
<[EMAIL PROTECTED]> writes:
Asger> We live in a wooden house with a spa, an extra room with a real
Asger> bed and an extra small house also with a semi-bed. There is
Asger> room on the floor for sleeping bags a
Angus Leeming wrote:
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UTF-16. See http://en.wikipedia.org/wiki/UTF-16.
Originally, all Unicode Windows feat
Georg Baum wrote:
Angus Leeming wrote:
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
We have of course one other options:
On linux: char_type is wchar_t
docstring is wstring
On windows: char_type is uint32_t
docstring is basic_string
Perhaps that is the easiest solution af
There is no libiconv.so
I thought iconv functionality was covered by glibc in Linux.
I have on my system /usr/local/lib/libiconv.so ...
Bo
Georg Baum wrote:
Abdelrazak Younes wrote:
I plan to first encapsulate the conversion to/from ascii inside each of
the filetools functions. Then I will look at how boost::filesystem can
handle unicode, if at all possible...
I am tempted to convert everything even when a std::string would
suffi
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | I think NTFS is UFT16...
> Hmm... strange choice imho.
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UT
As I recall, the windows version arrives with all fonts set to
something innocuous, like MS Sans Serif. It's easy enough to change
(so not a bug), but still, since as I understand it, all Windows
versions can be assumed to contain TimesNewRoman, Arial and Courier,
why not use them by default
1 - 100 of 174 matches
Mail list logo
