StableDocIterator::asDocIterator(InsetBase*) const by failing check
false in file ../../src/dociterator.C:566
--
Hopefully someone can help me to find a solution. Thanks for the work on
this great application!
Best regards,
Joost Verburg
The test document
StableDocIterator::asDocIterator(InsetBase*) const by failing check
false in file ../../src/dociterator.C:566
--
Hopefully someone can help me to find a solution. Thanks for the work on
this great application!
Best regards,
Joost Verburg
The test document
I'm a bit surprised that this doesn't seem to be a known issue. After
some more testing it looks like quite a major bug.
In the previous message I described a situation in which the cursor
misalignment causes a crash in combination with undo. Although this
happens often (I've had to use the
Not only the fractions itself cause problems, any equation that contains
a fraction triggers this bug. While sometimes characters are inserted
correctly when the cursor is wrong (although Undo gives a crash), it is
often not possible to insert a character using the mouse.
I'll give you an
Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin OK, here is the explanation (why not put it in a comment in
Martin the patch, if you can formulate a short one)
Thanks for the explanation. I changed the logic of the code (no more
go to the left and then to
Martin Vermeer wrote:
if you change
if (it != begin()
into
if (it != begin() currx = targetx
I expect Joost will find it behaving slightly better in the situation he
complained about. It won't fix everything though.
- Martin
I'll try this one.
With the last patch of
[EMAIL PROTECTED] wrote:
Hi,
I think INSTALL.Win32 is seriously out of date and needs to be looked over
by someonw who knows this stuff... Here's a patch where I'm *guessing* -
it should *not* be applied as it is.
INSTALL.Win32 is indeed outdated. It also points to the old kde-cygwin.
Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin if you change
Martin if (it != begin()
Martin into
Martin if (it != begin() currx = targetx
Martin I expect Joost will find it behaving slightly better in the
Martin situation he complained
Martin Vermeer wrote:
On Fri, 2006-02-24 at 12:45 +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin BTW Jean-Marc, this works, but would it perhaps be better to
Martin make MathNestInset inherit (from InsetBase) and modify
Martin covers(x,y)?
What is
Hello,
Again testing the latest development version of LyX 1.4 on Windows, I
have another problem.
I'm trying to insert one of the matbb/mathcal/mathrm symbols in a
document using the math panel, for example the double-barred R: \mathbb{R}.
Nothing appears on the screen and when I look at
Daniel Watkins wrote:
Within the maths environment of LyX, typing any of the above commands (in
this case \mathbb) creates an inset of that type (i.e. a box within which
everything typed will be in, for example, \mathbb). You then have to place
the cursor within this inset to use the font
Juergen Spitzmueller wrote:
you mean \mathbb{R}, then select and C-M?
Typing \mathbbspaceR gives the expected result to me.
Jürgen
The main problem is that the math panel doesn't work. Try to insert one
of the mathbb symbols using the math panel and you get an empty inset
instead of the
Juergen Spitzmueller wrote:
The main problem is that the math panel doesn't work. Try to insert one
of the mathbb symbols using the math panel and you get an empty inset
instead of the symbol.
I know, I can reproduce that. I just wanted to point out that the bug is IMHO
the same as the one
Martin Vermeer wrote:
Attached the best I can come up with for now. (...)
I propose this as the patch for 1.4.1 (not 1.4.0 I think; it's cosmetic
and there's a workaround).
But what about only the math panel issue? I think there should be at
least a patch to fix that in 1.4.0 since it is a
Georg Baum wrote:
Fortunately this is easy to fix, see the attached patch. (...)
I agree with Joost that it should be in 1.4.0. This is a major problem,
and LCursor::paste() is so utterly broken that every replacement that
works at least in one single case is better.
I have tested this patch
Martin Vermeer wrote:
This should improve things (untested)
- Martin
During more mathed testing, I found another issue. You can't reach the
position after the last bracket in this equation:
f=\frac{1}{\left(a\right)}\
Joost
Angus Leeming wrote:
Maybe I'm confused.
I think that I did build LyX 1.4 once or twice once I'd managed to turn off the
g++ safe iterators but the link time was over one hour with dynamic linking and
about 50 minutes with static linking.
I then went on to use Asger's VS2003 solution file and
Paul wrote:
2. Whenever I exited the program there was a fatal error (something about file
unlocking, I think).
I can reproduce this crash. Another issue with VC++ builds is that
console windows appear all the time when some process is supposed to run
in the background (image preview etc.).
Angus Leeming wrote:
Are you volunteering? You'd be made very welcome! (There are no active
developers using VS at the moment.)
Angus
I can help by pointing out the specific functions that cause the problems.
The console window issue is caused by spawnvp in support/forkedcall.c.
The MinGW
Michael Gerz wrote:
I cleaned up and updated my compile instructions (see attachment). If
you like to, you can have a look at my file and update INSTALL.Win32
accordingly (sorry, I will have no time before next weekend).
Thanks for these detailed instructions. Maybe it would be a good idea to
Michael Gerz wrote:
IMHO it is just that simple. Did you manage to compile LyX 1.4.0 with a
dynamic library?
Michael
I can compile it with both static and dynamic qtwin. Linking takes ages
with the dynamic library, but works.
What is the preferred method in terms of performance?
Joost
Angus Leeming wrote:
Yup. I've followed your prescription faithfully. The only change I've
made is to build and use qt.dll.
(I didn't compile the dictionaries either, but then I don't think that
you need to compile them; just grab 'em from the aspell site. AFAICT,
aspell-0.60 is perfectly
Angus Leeming wrote:
I'm still mulling over what to do with aspell. If we go for aspell 0.6
then it looks like I'll have to supply the dictionaries too. Would make
Kevin Atkinson happy :)
I just tested the new Aspell. Version 0.6 works fine and more recent
dictionaries are available compared
Angus Leeming wrote:
I'm not sure about concurrent LyX137 and LyX140 spellchecking
without alternating or changing the name of the folder called C:\Aspell
What is the reason of this hardcoded path? Although C is a common drive
letter, there are systems that do not use it or where people do
Angus Leeming wrote:
IIRC, it was a question of priorities. The path was hard-coded in Ruurd's
original port and when I integrated his work into the official LyX sources I
just used his code. It is certainly possible to set this path dynamically; we'd
have an entry in lyxrc.defaults/preferences
Angus Leeming wrote:
shrugTry it out and supply me with the details of what you did and I'll write
you a shell script to automate the process/shrug
My idea is:
PART 1 (SHELL SCRIPT)
-
* Extract the dictionary (say, aspell6-en-6.0-0.tar.bz2) in a separate
directory (for
the NSIS script to generate the installers. So
remove the zip part and instead call makensis like this:
makensis.exe /DLANG=en /DINPUTDIR=C:\Aspell\lib\aspell-0.60
/DOUTPUTDIR=C:\AspellDics AspellDicts.nsi
Joost
/*
NSIS script for Aspell dictionaries
Written by Joost Verburg
Currently
Stephen Harris wrote:
SH: I this packaging scheme adaptable?
The dict files went to C:\Aspell\data
Regards,
Stephen
You really don't want to package 80 languages manually. Using Angus'
shell script and my installer script all dictionaries will be
downloaded, compiled and packaged with an
Angus Leeming wrote:
Just thoughts, but I'm sure that they would be things that Kevin Atkinson would
raise. (The plan is to submit this stuff to Kevin, right?)
First of all they should be somewhere when LyX 1.4.0 is released. If you
want to submit them for the official site that's fine.
this should all work. (Maybe there is still a little typo in my
script but I need your shell script to test.)
Joost
/*
NSIS script for Aspell dictionaries
Written by Joost Verburg
To be used with the shell script of Angus Leeming
Required defines:
LANG - language code
INPUTDIR - directory
Angus Leeming wrote:
We don't use aspell.exe. We link aspell.lib statically into lyx.exe. It's
perfectly possible to install (and use) the dictionaries without installing
aspell.exe.
Then I don't really understand why Windows users should install their
dictionaries in
Angus Leeming wrote:
I think that the Aspell dictionaries aren't our business. We shouldn't
package them with LyX. Uwe can throw them into his installer if he likes
(it's his installer after all :)) but LyX itself shouldn't have to look
for these dictionaries in a hard-wired location. The
in the attached script.
Hopefully uploading did not take you too much time.
Joost
/*
NSIS script for Aspell dictionaries
Written by Joost Verburg
To be used with the shell script of Angus Leeming
Required defines:
LANG - language code
INPUTDIR - directory with compiled dictionary files
Angus Leeming wrote:
Thanks for this report, Stephen. Joost are you reading?
These data files are indeed also required. It looks like we have to
create an installer for Aspell itself as well.
Joost
Angus Leeming wrote:
I see an installer at http://aspell.net/win32 for aspell 0.5. Can you
reuse that or would it be easier to start afresh with NSIS?
I wrote an installer for Aspell 0.6 and an updated dictionary installer.
However, things seem to be a little more difficult.
The
Kevin Atkinson wrote:
Thanks. I will look at these sometime this or next week and if things
look OK will upload them to the Aspell site. BY I post your email in
case others have problem with them. I personally am not willing to
support them.
I'm currently finishing a Windows installer for
Using the latest CVS version of Aspell should improve the situation.
However, I cannot get it to compile. Msybe you can have a look at it?
Joost
/*
NSIS Script - Aspell 0.6 Dictionary Installer for Win32
Written by Joost Verburg
To be used with the shell script of Angus Leeming
Required defines:
LANG - language code
INPUTDIR - directory with compiled dictionary files for the language
LISTDIR - directory that contains
Michael Gerz wrote:
when I run the configure script for BRANCH_1_4_X on Windows (MinGW), I get the
following error message:
checking types of arguments for select... int,int *,struct timeval *
./configure: line 34926: syntax error near unexpected token `s/^\\(['
./configure: line 34926: `
Stephen Harris wrote:
I put this file and explanation on the LyX Wiki so there would
be no hurry to finish the Aspell project for .60.4 and also LyX
has a spellchecking bug that won't be fixed until 1.4.1 so users
could go on using spellchecking in LyX137 if they so choose.
The problem with
has uploaded the installers (I have no access to the server), they will
be ready for everyone to use.
Joost
aspell_dict.sh
Description: application/shellscript
/*
NSIS Script - Aspell 0.6 Dictionary Installer for Win32
Written by Joost Verburg
To be used with the shell script of Angus
Joost Verburg wrote:
The installers (one for the data files and lots of dictionary
installers) are finished. I attached all files to build them. Once Angus
has uploaded the installers (I have no access to the server), they will
be ready for everyone to use.
Minor update: Add --ignore
Georg Baum wrote:
The only dependency on sh is now the graphics conversion script that is
built on the fly and some smaller scripts in lib/scripts, but the main
advantage for me is that maintenance of configure.py is easier than that
of configure.m4
If you could get rid of the sh usage in
.
Joost
/*
NSIS Script - Aspell 0.60.4 Data Instaler for Win32
Written by Joost Verburg
Compile this script using makensis in a directory that contains an
installed version of Aspell 0.60.4
You should also copy the file COPYING to this directory
(for the license information).
Note that this script
Angus Leeming wrote:
Am I right in thinking that I don't actually need to use this again? Ie, the
AspellData-0.60.4.exe that's on the wiki is perfectly fine for LyX's purposes?
Assuming that's the case, why not try and upload this .nsi script to the wiki
yourself?
Angus Leeming wrote:
Ok, I know that I'm a bit behind the times, but I've just uploaded
LyX/Win 1.3.7-3 to http://wiki.lyx.org/Windows/LyX137. This thing uses
the new Aspell dictionaries and seems to work well.
Moving on to LyX/Win 1.4, what should I compile? The release tar ball or
a
Jean-Marc Lasgouttes wrote:
We could have a network installer and a full installer. I really think
the two installers should merge.
Exactly what I mean. There should be one standard and official installer
that contains only LyX itself but downloads and installs all required
components
Bo Peng wrote:
OK. Let us decide first what should go into this session file, and how
to name them (will be used in either .ini format or XML format).
5. Lyx window position when closed?
6. Lyx window size when closed?
I don't know what the Linux/Mac situation is, but LyX for Windows always
John Spray wrote:
I would recommend against remembering window position. Good window
managers make an effort to place a new window such that it occupies any
blank space available.
Maybe Linux window managers have some logic to position windows nicely,
but it is common for all Windows
Charles de Miramon wrote:
Why not make things simple. I'm in favour of Bo Peng's approach. Power users
can always use the -geometry option from the command line. Or if they use,
KWin use the advanced options for windows placement where you can tweak
parameters forever.
The -geometry option
Juergen Spitzmueller wrote:
lyx -geometry 1280x1024 works perfectly for me (qt/linux).
Right, the man page says it's an xforms option, but it also works for
Qt. I agree with Lars that it would a good thing to have this both as a
preference and as a part of session handling (if possible, for
Bo Peng wrote:
Now, we have
1. lyx --geometry
2. lyxrc
3. session()
How do you plan to let them work together?
In my opinion sessions are the most important thing. It would however
also be nice if you could set a static session for window sizes. That
is, have a standard set of window
Bo Peng wrote:
This makes sense. I propose a lyxrc entry windowSize that
1. has value (0,0) by default.
2. If lyxrc.windowSize==(0,0), saved window size from session() will
be used. (If no session() info, use hard-coded default)
3. if lyxrc.windowSize != (0,0) (being assigned a value using a
Bo Peng wrote:
The weird part is, -I./interfaces/cc/ has aspell.h. Any clue?
Bo
Yes, you should upgrade to the latest candidate releases of MinGW/gcc.
The current stable version (3.4.2) gives this error.
Joost
Hello,
I'm again testing the LyX 1.4.x branch and found another annoying bug.
When the Graphics dialog is opened to modify the properties of a
graphic, and no information has previously been entered on the Clipping
tab, LyX activates the Get from File function and grabs the bounding
box
Hi,
Another day, another bug :) Today I had some crashes while working with
math. They seem to be related to pasting with the middle mouse button,
math mode and undo.
The crash can be reproduced by opening a new document, going into math
mode and then pressing the middle mouse button
Bo Peng wrote:
0. bug 686: del [|] remoes the whole inset, implemented
That is the expected behavior, it's a valid bug and should be fixed.
1. del at [abc|] work as backspace (instead of doing nothing)
It should do nothing. Working like backspace is non-standard and
unexpected
Bo Peng wrote:
Is [abcdf|] + del = |[abcd] a sound behavior by your standard?
Of course I mean the current behavior [abcd|] + del = |[abcd] . This
behavior actually triggered my above ideas.
In my opinion del should do nothing here.
Joost
Jean-Marc Lasgouttes wrote:
So what is needed for 1.4.1 now?
Martin's patch to fix the math crashes and bug 2485 should go into 1.4.1.
A good patch for the cursor regression (bug 686) would be a nice thing
to have, if available soon.
Joost
Martin Vermeer wrote:
It should first go into 1.5... is everybody happy with it?
It works fine for me.
Joost
Some vendors of anti-virus software often make the mistake to include an
installer system in the virus definitions whenever a malware application
uses that system, instead of targeting the malware itself.
This should be reported as a false positive.
Joost
Lars Gullik Bjønnes wrote:
Can
Angus Leeming wrote:
NSIS doesn't support Win98, period.
As one of the NSIS developers, I can assure you that this is definitely
not true. NSIS has always been designed to support all Win32 versions,
even the very first editions of Windows 95 are still supported and tested.
Problems with
Angus Leeming wrote:
It would be interesting to track that down, no?
I just tested the installer on Win98 and it indeed crashes. The crashes
however seem to be related to the custom dialogs and not the plug-in.
One first thing to check is whether all dialog INI files on your build
system
Angus Leeming wrote:
Anyway, thanks for confirming that these .ini files are OK. Now that I know
that the thing *should* work with Win98, I'll investigate further.
Good news. After I compiled the plug-in and recompiled the installer, it
works fine on Win98. So maybe the way you compile the
Angus Leeming wrote:
Interesting. Could you post the details of your compiler, compiler command,
the system you compiled this on, version of NSIS etc.
Are there any introspection tools that can compare two ostensibly identical
installers and highlight the differences?
It's definitely related
Angus Leeming wrote:
A. Interesting indeed. I compiled the plugin with g++. I take it that NSIS
itself is compiled with VS? I'll recompile with VS.
NSIS itself is indeed compiled with VS, but plug-in don't have to be
compiled with VS. There are even some Delphi plug-ins that work.
I'm
Jean-Marc Lasgouttes wrote:
No it tells the user please browse you hard disk to find a suitable
application. And it forgets to add good luck. I do not see how
someone is going to think about installing gsview.
The right place to help the user pick the right programs is the
installer. This is
Uwe Stöhr wrote:
2/ ask windows what viewers are available at runtime, and make them
available.
This is also already the case.
But it doesn't work when you install or move a viewer after installing
and configuring LyX. This is the most important thing that should be fixed.
In my opinion,
Uwe Stöhr wrote:
This is then not an installer issue. LyX's configure should indeed be
able to check for installed viewers, so that you can in this case simply
run reconfigure. At the moment you have to change the path in LyX's
preferences.
The idea is to check for viewers at LyX startup, so
Jean-Marc Lasgouttes wrote:
It looks like a good plan. What is really strange though is that the
is no API to do this really simple task without reading the registry.
This is wrong. The system for Windows file associations has quite some
options and does not work this way.
It makes no sense
Bo Peng wrote:
I am deciding what to do next with lyx. The windows side is obviously
the weak part of lyx so I think I can do something with the official
installer, or the cygwin one. If you can hang on and help me, can we
try together? (I think Uwe's installer is good enough now, I got
another
Jean-Marc Lasgouttes wrote:
This is my long announced patch to remove the need to create
lyxrc.defaults and friends in the main support directory (and build
directory). I really would like to see some good testing of this one,
including on windows and osx. This one is for 1.5, I can provide a
Jean-Marc Lasgouttes wrote:
This patch closes the improvements I had in mind concerning
installers. It allows packagers to provide a file lyxrc.dist that will
be read (if it exists) before all the others. No such file is
distributed by LyX currently, but it can replace the preference file
Jean-Marc Lasgouttes wrote:
Joost == Joost Verburg [EMAIL PROTECTED] writes:
Joost The idea is to have no lyxrc.defaults, textclass.lst and
Joost packages.lst in the LyX directory but only in the users
Joost directory?
Yes.
Joost It doesn't seem to work on Windows. When I start LyX
Bo Peng wrote:
Bo 1. free of license problem (legal) 2. only have the essentials
Bo (small). 3. try to support a wide range of settings 4. and try not
Bo to require administrate privilege
This looks good, although there may be a case for a version that
contains everything needed or has code to
Bo Peng wrote:
So at least python.exe, sh.exe etc will be in, right? Installing full
python and msys is unacceptable even if they are downloaded
automatically.
Yes, these very essential GPL-compatible things (LyX won't configure or
run without them), will be bundled. It is indeed nonsense to
Uwe Stöhr wrote:
Why that? What's the problem with my installer - the needed admin
permission? If this is the only problem I suggest that you work on this
and send patches to my installer. Because there's no need to do the work
twice.
I spent a lot of time on the installer and it is sad to
Uwe Stöhr wrote:
I'm advertising my installer solution here not only because of the
installer itself, it costs more time to get the installer working with
the third party programs. The actual MiKTeX version was build for my
installer and some new features are in now to be able to configure
Uwe Stöhr wrote:
I've seen you on the NSIS-lists and know that you'll build us a perfect
installer. I now understand what you want to achieve. A thing that is
missing in my installer is indeed a method to update only LyX or only a
third party program when there's a problem with it.
Exactly
Jean-Marc Lasgouttes wrote:
Could you try one of the following patches? They make sure that
reconfiguration is done if lyxrc.defaults is not found.
JMarc
It still doesn't work on Windows. Again, when no configuration files
exist, I get the error unable to find textclass file. It looks like
Jean-Marc Lasgouttes wrote:
Try these updated patches. This is really embarassing, Georg pointed out the
bug a long time ago, but for some reason I did not look at it at the
time.
Still no difference, same error. Note that it does reconfigure when I
put some old textclass.lst in
Jean-Marc Lasgouttes wrote:
Weird. Could you send the result of lyx -dbg init,tclass?
Initializing LyX::init...
About to read lyxrc.dist... Found in c:/Program
Files/LyX14/Resources/lyxrc.dist
About to read lyxrc.defaults... Not found.
About to read preferences... Not found.
About to read
Jean-Marc Lasgouttes wrote:
Joost Still no difference, same error. Note that it does reconfigure
Joost when I put some old textclass.lst in Resources\lyx. So it
Joost probably looks for textclass.lst before it gets to this code in
Joost lyx_main.C.
Is it that you have lyxrc.defaults, but not
Uwe Stöhr wrote:
Right, but the installer is for all users. Only a few users know the
details about graphics. Most of my collegues for example used EPS-images
because they didn't know that PDF can embed JPG, PNG and PDF-images
directly. So the installer must include Imagemagick by default
Bo Peng wrote:
This is perhaps unrelated. The biggest advantages of SWP, according to
one of my friends, is that one can paste windows wmf figures directlry
to SWP. I do not know how SWP is handling that, but from what I
searched last time, there is no usable WMF-whatever converters.
SWP has
Jean-Marc Lasgouttes wrote:
Joost No, see the debug output I mailed earlier today.
This one misses the package.../package part. Could you add it?
That part is totally normal, see below.
Joost I have no configuration files (except lyxrc.dist) at all in
Joost both the LyX Resources directory
Uwe Stöhr wrote:
What is SWP?
Scientific Workplace.
LyX with Imagemagick can handle wmf-images. I attached a LyX file and a
wmf-image to test this.
WMF is a vector format. ImageMagick can only convert this to a bitmap,
so you loose all quality.
Joost
Uwe Stöhr wrote:
That's the same as for SVG-images. But the bitmap looks readable.
Nervertheless the Imagemagick people are working on a vector graphics
rendering engine but this is at the moment far from beeing complete.
Also Acrobat can't handle WMF. Do you know a program that could convert
Jean-Marc Lasgouttes wrote:
Is python available when you run LyX? It should be in the path at the
first run, I guess. If you added it to extra_path in lyxrc.dist, then
the fix would be to load lyxrc.dist before trying to reconfigure.
Does this make sense?
Python is available and has been
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus * control the compilation of
Angus development\Win32\packaging\installer\lyx_configure.C from a
Angus Makefile.am
Is this lyx_configure still needed?
With the new configure.py, this one is not needed anymore.
Jean-Marc Lasgouttes wrote:
I meant path_prefix. The problem was that reconfiguration was done
before readong lyxrc.dist.
Try the following (I did not test it).
There are still two major issues:
* The rest of the code doesn't wait for configure.py to complete. Since
this takes a few
Jean-Marc Lasgouttes wrote:
Wow! You always manage to both find new bugs...
I assume the problem is that system() does not wait for completion on
windows, right?
Yes, indeed.
So how do we execute a program and wait for termination?
Look how it is done in the Reconfigure function in
Hi,
While working on the new Windows distribution for LyX, I found two more
bugs.
* The file selection dialog doesn't allow you to select files from C:\
(other root directories like D:\ work fine).
* When ImageMagick is used to convert images for preview, the text
Error converting to
Hi,
Now that configure has moved to Python, there are only a few small shell
scripts left.
It would be great if those could be converted to Python as well, so that
we can finally get rid of the MSYS requirement on Windows. Moreover,
it will increase performance a lot.
Regards,
Joost
Jean-Marc Lasgouttes wrote:
Joost Look how it is done in the Reconfigure function in lyx_cb.C.
That is what I did at first, and I came up with the attached.
Great, finally it works fine! Please put it in.
Joost
Hi,
status.14x contains the following line:
- Make LyX/Win work under windows 98.
This is incorrect. Although LyX 1.4 itself supports Windows 98 and ME,
Q../Free doesn't work on these versions (LyX will start but the UI is
completely unusable). Thus the supported versions are currently
Angus Leeming wrote:
I guess that depends on what you mean by supported. LyX on Win98/ME *has*
worked in the past thanks to the diligent efforts of Luis Rivera in showing me
what needed to be donw. It *has* worked with Q../Free too, but since these guys
don't have access to such venerable
Angus Leeming wrote:
If we know which version works we could make that one available for
Win98/ME or try to find the issue by looking at the differences.
TO be honest, no, I don't know. Try getting in touch with Luis; he's certainly
used LyX on these OSes.
By the way, wouldn't it possible to
Angus Leeming wrote:
LyX is licenced under the GPL. Linking to non-open source libraries is
restricted to system libraries as a special exception in the license, no? Qt
doesn't count as a system library.
So, no, that's not an option.
Have patience though. Qt4 *is* licenced under the GPL.
Andre Poenitz wrote:
Could you scetch the problem?
I don't know the details, but I think you need a commercial license if
you develop with Qt3. Creating an installer is also developing.
For normal Windows development Q../Free is fine. It would however be
great to have stable installers
1 - 100 of 2160 matches
Mail list logo
