On Tue, 2006-09-12 at 16:38 +0200, Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
|
| 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
Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| Isn't this what svn, the version control system is for?
| If the spellchecker is removed and the new one takes
| too much time, you can get impatient and revert the removal?
Exactly. Of course only if you don't combine
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 falling behind by not being actively maintained. I
Martin mean, the qt version _looks_ good.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Lars Gullik Bjønnes wrote:
| | Abdelrazak Younes [EMAIL PROTECTED] writes:
| | #ifdef NEW_CODE
| | #endif
| | or:
| | create new
John == John Levon [EMAIL PROTECTED] writes:
John On Mon, Sep 11, 2006 at 09:10:08PM +0200, Michael Gerz wrote:
Decide on your own what that means for Qt3...
John One small note: if qt3 dies (and the development cost does seem
John quite onerous), then the first 1.5.0 release should have clear
Peter == Peter Kümmel [EMAIL PROTECTED] writes:
Peter Just complaining about the crying wolfs is not enough, only
Peter arguments count. But each change has it risk, and I understand
Peter that someone people think some changes are too risky, because
Peter each decision could be wrong.
Peter
Georg Baum [EMAIL PROTECTED] writes:
| | 1.5 is not in a useable state right now anyway, how about just
| | seting a time limit on this removal thing?
|
| Perhaps then we should get it into usable state before we do anyting
| else...
| It just crashes for me...
|
|
Georg Baum wrote:
Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| Isn't this what svn, the version control system is for?
| If the spellchecker is removed and the new one takes
| too much time, you can get impatient and revert the removal?
Exactly. Of course only if you
Charles == Charles de Miramon [EMAIL PROTECTED] writes:
And also there are many people, who do not upgrade his/her distro
that frequently. (For example I use SuSE 9.3 at home, simply
because I prefer gcc 3.3 over 4.0 on that particular machine and I
find it very difficult to downgrade in
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Therefore, we should support qt3 for at least three years for
*NIXes. For WINDOWS and Mac, we can just drop it.
One more thing, If you have difficulties maintaining qt3 frontend,
I can try to handle it.
Helge Now that is a solution too, of
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 falling behind by not being actively maintained. I
Martin mean,
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Lars Gullik Bjønnes wrote:
| | Abdelrazak Younes [EMAIL PROTECTED] writes:
| | | Lars Gullik Bjønnes wrote:
| | | Abdelrazak Younes [EMAIL PROTECTED] writes:
| | |
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak José Matos wrote:
That is the problem with the cry wolf type of strategies, they
are good in the short term and bad in the long term.
Abdelrazak I agree but the problem in this list is that questions and
Abdelrazak opinions
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Year... with the amount of time spent in this whole discussion, I
| think the whole stuff would have been finished by now.
Yes. If you had done what I say or a lest tried to ease my concerns
with some alternative approach you would have been done
Uwe Stöhr wrote:
We should get rid of clean_dvi.py as it prevents many LyX-files to be
converted to DVI (tested under MiKTeX and TeXLive). I described the
problematic in detail in bug 2836
http://bugzilla.lyx.org/show_bug.cgi?id=2836
The problem occured in february this year when MiKTeX
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Georg Baum wrote:
| Lars Gullik Bjønnes wrote:
|
| Helge Hafting [EMAIL PROTECTED] writes:
| | Isn't this what svn, the version control system is for?
| | If the spellchecker is removed and the new one takes
| | too much time, you can get
Lars Gullik Bjønnes wrote:
You are not even listening.
As I said Dialogue de sourd! I think the same of you ;-)
Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael Jean-Marc Lasgouttes schrieb:
This notion that change is always progress is pure bullshit.
Michael I agree with you to some degree. However,
Michael - there is some evidence that qt4 is superior to qt3 (at
Michael least some people
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Georg Baum wrote:
| Lars Gullik Bjønnes wrote:
|
| Helge Hafting [EMAIL PROTECTED] writes:
| | Isn't this what svn, the version control system is for?
| | If the spellchecker is removed and the new one takes
| | too
Jean-Marc Lasgouttes wrote:
And there is nothing that the qt4 version can do that cannot be done
by qt3 (which was not the case with xforms).
Qt4 brings some new stuff that could be useful for Lyx :
- Code highlighting widget (would be very nice for the LateX preamble)
- Autocompletion for
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
And there is nothing that the qt4 version can do that cannot be
done by qt3 (which was not the case with xforms).
Abdelrazak Correction. The model/view separation in qt4 is something
Abdelrazak that is easily achievable by qt3.
Do
Abdelrazak Younes wrote:
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 falling behind by not being actively
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| I think you still don't understand the problem and I am tired of it. I
| am done with it.
Lars Nice way of being stuck in your own mindset.
I think you should both take a break before continuing this
discussion.
JMarc
Lars Gullik Bjønnes wrote:
I have introduced a lyx::char_traits, and use that when defining
docstring, this should perhaps give us a bit better control.
I think this will work, but have not been able to test yet. (Busy
compiling when I left for work.)
My tests show that the std char_traits
Jean-Marc Lasgouttes wrote:
Note however that this qt4 frenzy is just an historical accident:
That part is true.
Abdel wanted qt4 because mingw is too slow.
Man, you are rewriting history ;-)
For the record. I started with mingw and stayed with it a long time
until Bo provided scons.
On Wednesday 13 September 2006 10:50, Abdelrazak Younes wrote:
But I think it is time now to see it over fresh eyes and to allow some
more liberties in the LyX development model. I think manpower would come
naturally if you allow that more liberty.
The problem is that is always the same
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 is no free lunch, as was
said earlier.
You are playing the devil's advocate
Charles == Charles de Miramon [EMAIL PROTECTED] writes:
Charles You know it can be fiendieshly difficult to compile a recent
Charles program on an old Linux. What has caused the most problem for
Charles KDE is not the changes of Qt version but the breakage of the
Charles C++ ABI, add to that
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdel wanted qt4 because mingw is too slow.
Abdelrazak Man, you are rewriting history ;-)
I thought you stated it again recently. Since I am too lazy to search
the archives, I'll just retract the argument :)
Abdelrazak For the record.
Rainer == Rainer Dorsch [EMAIL PROTECTED] writes:
Rainer So that means lyx 1.4.2 does not support qt 3.0.x, right?
Rainer If yes, someone should update the README for 1.4.3. It says
Rainer that even QT2 might be supported though untested. This would
Rainer mean at least qt=3.1 is required.
I
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 everywhere is a Qt4 installation
then you would drop qt3 immediately?
So we could
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 everywhere is a Qt4 installation
then you would drop qt3
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc We already have the problems of gcc versions, autotools
Jean-Marc version and friends and we do deal with them as well as you
we-^^^
Jean-Marc can.
JMarc
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdel wanted qt4 because mingw is too slow.
Abdelrazak Man, you are rewriting history ;-)
I thought you stated it again recently. Since I am too lazy to search
the archives, I'll just retract the argument
Asger Ottar Alstrup wrote:
Please let me know fast when you want to come. Please also tell me if
you are NOT coming, because that helps me understand when I do not have
to wait anymore to confirm.
I can't come.
Georg
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Slightly better patch.
Does not work for me :(
JMarc
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg Slightly better patch.
Does not work for me :(
As I wrote: It does neither for me. For anybody who wants to do further work
on LyX until Lars and/or I have sorted this out I suggest to apply the
attached
Enrico Forestieri [EMAIL PROTECTED] writes:
Please verify which Typewriter font you have set in
Tools-Preferences-Screen fonts
I am using the Typewriter fonts that was used as default when I snstalled LyX
1.4.2, which is MS Shell Dlg.
I have tried to used other screen fonts, with no
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 and dv2dt?
They should not,
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
I won't have time to test it today or tomorrow, though.
Juergen Anyone else? If not, I propose to shove it into trunk.
Juergen I'd really like to have this bug fixed as well for 1.4.3,
Juergen though -- it annoys me a lot.
Please
Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael John Levon schrieb:
Unfortunately the menus are the essence of compromise...
Michael Than let's find a solution that everybody can agree upon. If
Michael JMarc is willing to fix #2491 (easy), I will no longer insist
Michael on noun,
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin But why even take the risk? Why not add enchant support first
Martin -- and do all the controller sanitizing this may require --
Martin and only THEN start removing things?
Considering that aspell lib support is there, it cannot be so
José Matos wrote:
On Wednesday 13 September 2006 10:50, Abdelrazak Younes wrote:
But I think it is time now to see it over fresh eyes and to allow some
more liberties in the LyX development model. I think manpower would come
naturally if you allow that more liberty.
The problem is that is
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 and so on, so we should be
Asger able to host all that want to
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 and so on, so we should be
Asger
Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin But why even take the risk? Why not add enchant support first
Martin -- and do all the controller sanitizing this may require --
Martin and only THEN start removing things?
Considering that aspell lib
Am I right that all of the filetools.h API should be converted to docstring?
I have started the conversion already so please tell me quick if that's
not the case.
Abdel.
On Wed, Sep 13, 2006 at 12:15:55PM +, Andreas K. wrote:
Enrico Forestieri [EMAIL PROTECTED] writes:
Please verify which Typewriter font you have set in
Tools-Preferences-Screen fonts
I am using the Typewriter fonts that was used as default when I snstalled LyX
1.4.2, which is MS
Georg Baum wrote:
Why is this thing so difficult? It should be no problem to let Abdel work on
the spell checker stuff exactly as he likes if he promises to finish it
completely, with configure support, preferences and all, and support for
aspell and ispell, either via enchant or directly in
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Considering that aspell lib support is there, it cannot be so
difficult to add enchant?
Abdelrazak No it is not. But that is not my point... I wanted to
Abdelrazak start clean from the beginning. Adding Enchant would not
Abdelrazak
Abdelrazak Younes [EMAIL PROTECTED] writes:
| | work will not be so much.
| | | At least someone who can think logically!
| Yes, I have noticed that you enjoy arguments that fits your own
| beliefs.
|
| Would you like me to dislike arguments that I agree with?
No, but allow for the fact
Georg Baum [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| I have introduced a lyx::char_traits, and use that when defining
| docstring, this should perhaps give us a bit better control.
|
| I think this will work, but have not been able to test yet. (Busy
| compiling when I
Hello,
Following the thread about Qt3, I would like to experiment creating a Debian
package of Lyx-Qt4
Trying scons, I'm quickly stopped :
tombouctou:/usr/local/src/lyx-devel# scons -f development/scons/SConstruct
qt_lib_path=/usr/include/qt4 qt_dir=/usr/include/qt4
extra_lib_path=/usr/include
[EMAIL PROTECTED] wrote:
URL: http://www.lyx.org/trac/changeset/14983
Log:
Compile fix for the case when USE_BOOST_FORMAT is 0
* src/support/lstrings.C
(bformat): Add missing lyx::from_ascii()
Does this not work:
template
docstring convertdocstring(unsigned int ui)
{
-
--- Uwe Stöhr [EMAIL PROTECTED] wrote:
I mean we can get rid of the clean_dvi.py script because the yap and
dvips versions delivered with MiKTeX 2.5 should be able to handle the
cases the script was built for. If not (I couldn't test it because I
don't have a testfile) we should contact
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I have started the conversion already so please tell me quick if that's
not the case.
You will probably need to add
Angus Leeming wrote:
Does this not work:
template
docstring convertdocstring(unsigned int ui)
{
- return lyx::from_ascii(lexical_caststring(ui));
+ return lexical_castdocstring(ui);
}
?
I did not try. I simply copied from the other specializations. It should
work in
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 tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not sure if a blind conversion is
Lars Gullik Bjønnes wrote:
Yes, but we should perhaps use our own char_traits (as we have to on
older gcc and windos (??)) we should do this explicit instead of
through std::char_traits specialisation.
Not on windows, the STL of VC++ is pretty good (as you would expect since it
is from
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.
Well, the keep it simple principle applies - users
actually understand the filesystem, so there
Georg Baum wrote:
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I think we should support that indeed.
I have started the conversion already so please tell me
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 tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Lars Gullik Bjønnes wrote:
Filesystems and unicode is tricky.
And I am not sure if a blind conversion is the way to go.
But, yes, I think we should allow for utf-8 filesystem (I do not think
anyone uses utf-16 in the filesystem?)
I'd prefere is most of this work tried to leverage
Trying scons, I'm quickly stopped :
tombouctou:/usr/local/src/lyx-devel# scons -f development/scons/SConstruct
qt_lib_path=/usr/include/qt4 qt_dir=/usr/include/qt4
extra_lib_path=/usr/include all
scons: Reading SConscript files ...
Checking for pkg-config...yes
Checking for main() in C library
Please let me know fast when you want to come. Please also tell me if
you are NOT coming, because that helps me understand when I do not have
to wait anymore to confirm.
Very tempting. If there were no 911 so people can actually go back to
the states without 6 month background check... I would
Georg Baum [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| Yes, but we should perhaps use our own char_traits (as we have to on
| older gcc and windos (??)) we should do this explicit instead of
| through std::char_traits specialisation.
|
| Not on windows, the STL of VC++ is
Bo Peng [EMAIL PROTECTED] writes:
| Please let me know fast when you want to come. Please also tell me if
| you are NOT coming, because that helps me understand when I do not have
| to wait anymore to confirm.
|
| Very tempting. If there were no 911 so people can actually go back to
| the
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 tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Am Mittwoch, 13. September 2006 12:42 schrieb Jean-Marc Lasgouttes:
Rainer == Rainer Dorsch [EMAIL PROTECTED] writes:
Rainer So that means lyx 1.4.2 does not support qt 3.0.x, right?
Rainer If yes, someone should update the README for 1.4.3. It says
Rainer that even QT2 might be supported
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_stringuint32_t
Perhaps that is the easiest solution after all?
Works only for
Bo Peng wrote:
Trying scons, I'm quickly stopped :
tombouctou:/usr/local/src/lyx-devel# scons -f
development/scons/SConstruct qt_lib_path=/usr/include/qt4
qt_dir=/usr/include/qt4 extra_lib_path=/usr/include all
scons: Reading SConscript files ...
Checking for pkg-config...yes
Checking
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 tell me quick if
| | that's not the
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
suffice. For
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_stringuint32_t
Perhaps that is the easiest solution after
Angus Leeming [EMAIL PROTECTED] writes:
| 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_stringuint32_t
|
|
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
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
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
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:
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_stringuint32_t
Perhaps that is the easiest
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
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 and so
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 this
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
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 and
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
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
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
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 is
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
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
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 (but
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
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.
Well, the keep it simple
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
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
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 [EMAIL PROTECTED] writes:
Angus Leeming wrote:
Abdelrazak Younes younes.a at ... 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
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
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
1 - 100 of 348 matches
Mail list logo
