I have a problem that Qt doesn't let me create Qt application - there is no such option in "New Project" - but only under my Windows. Under Linux it works like a charm.
I have installed package Qt+QtCreator from official Qt's download page.
I have already looked it up on google and I found answers here, on stackoverflow, but everybody suggest to add Qt to build toolkits in configuration. That's not problem in my case - QtCreator detects my Qt automatically and correctly:
This still doesn't let me create Qt app:
(it's in polish, but it says that only possible projects are non-qt and imported projects).
I have checked if qmake.exe pointed by the Qt that QtCreator is using works - yes, it works.
What else can I check/do?
Based on your comment, it seems that you are using Windows XP. That is not supported anymore. It was dropped a while ago. It may or may not work, but overall, it would be bad experience in the majority of the cases because things like your issue is also somewhat fundamental.
The currently supported Windows variants are Windows 7 and 8. I think it is a wise decision to upgrade if you can or look for an Integrated Development Environment that is still well supported on Windows XP. That means you could also get an older version of QtCreator, but it would probably be behind Qt 5 feature support now.
The problem here was the Windows XP. Using more recent Windows version fixes the problem.
You can downgrade Qt to latest version which supports Windows XP (OpenGL?), AFAIK v5.1.1. It can be installed via current online installer.
Edit: but I found it's pretty unstable (hence I using Qt running on Linux via VirtualBox).
Related
On our PC (under Windows XP there is MiKTeX, and it have been working well for many years. However, several month ago, after installing the latest version (setup from 09/16/2017), dvipdfmx stopped working reporting something like 'it is not win32 application'. It has been appeared that the problem is arisen by mgs.exe (ghostscript for MiKTeX). The first thought was that a 64-bit version of mgs.exe was mistakenly included into 32-bit MiKteX. However, it is appeared not the bug: MiKTeX team says that it is worked under 32-bit Windows 7.
I do know that officially MiKTeX now requires Windows 7 or higher (so, XP is not supported). However. it was perfectly well until the latest update, and even now latex.exe, yap.exe and others still work. So, the question: is it possible to go the problem around within XP?
Without knowing what the actual problem is, its impossible to offer any advice. When quoting errors it is important to quote the exact error message.
"Something like 'it is not win32 application'" is not precise enough.
This is also not a Ghostscript question, because 'mgs.exe' isn't Ghostscript, its clearly a fork of some kind.
My guess is that its the fact you are using an ancient version of Windows, most likely the application is no longer compatible with such an old version, possibly because whoever built it is using a newer version of Visual Studio.
In order to build Ghostscript for Windows XP I think you need to use Visual Studio 2005 or earlier, a more recent version will create an executable that will not run on Windows XP.
The only solution to this would be to build 'mgs.exe' with an older version of Visual Studio, or try the pre-built executable 'gswin32.exe' which is available from the ghostscript.com website in the downloads section. Obviously that's not the same as mgs.exe, but I can't help you with a fork since I have no clue what's been done.
The first thing to try is running 'mgs.exe' from the command line, if that fails to work then its almost certainly because the developer who built it used too recent a version of Visual Studio.
If this is the case then no, you can't fix it within Windows XP, you need to do one of:
1) Upgrade to a newer OS
2) Downgrade your MikTeX and live with the older version until you are prepared to upgrade your OS.
3) Rebuild 'mgs.exe' yourself using an old version of Visual Studio. This could be challenging because I can't find anywhere on the MikTeX website where they make the source files available. I've been to their Github repository and I can't find anything from Ghostscript there either. I'm going to have to contact the developers, they are not using a stock version of Ghostscript, they do not appear to make their revisions available, ansd although they correctly reference Ghostscript as AGPL I cannot see anywhere in the install or their Github repository which lists Artifex as the owner or points to the Artifex website. They also don't copy the Licence or readme files (slapped wrists for them).
I was going to try using the regular Ghostscript instead of the modified version, but I don't have know anything about MikTeX so I have no way of testing whether that works. It looks to me like it probably would, since it appears that MikTeX forks Ghostscript as a process. So copying and renaming the 64-bit Windows version of Ghostscript's binaries would probably work.
As you note, the developers state themselves that they no longer support Windows XP.
Short version:
When I moved to Win7, I manually removed the MDAC 2.7 lines from my .ISM module, built it, and installed my software. It seems to work. Can I trust it?
Longer version:
We have just gone from XP to Windows 7. The software we deliver is C# (.NET 4 framework), targeting XP and Windows 7. It contains a few older COM modules, one of which is written in VB6. (Yes, I would love to rewrite this in a modern technology, but that's not an option at this point.)
I use InstallShield 2010 to build the installer for this package. Building this installer on XP worked with no problems. When I try on Windows 7, it wants MDAC 2.7 as a prerequisite merge module. Microsoft doesn't allow you to download 2.7 anymore, and I'm not going to get it from "Sharewarez R'us" sites.
The error InstallShield gave me when it couldn't find the merge module was: File not found. An error occured merging Module 'MDAC27ENU...'
From what I've read on the web, Windows 7 has the latest-greatest MDAC (now renamed WDAC) already installed. On a whim, I manually deleted the MDAC dependencies from the .ISM, built and installed, and my software seemed to run just fine.
What I think is happening is Win7 is noticing that something in VB6 is using MDAC and the OS is supplying the latest-greatest and it just works. I no longer need the merge module because Windows 7 has WDAC built in. (Can it really be that simple?)
My main question is: can I trust it?
My secondary question is: What about XP deployments? They will still need MDAC 2.7... Does that indicate I can't build on Windows 7 to target XP if I require MDAC 2.7? Please point me in the right direction. Thanks.
You need a comprehensive review (dependency analysis) of your installer. The VB6 runtime and MDAC/WDAC components are all built into windows these days. This is also the case with Windows XP and the latest service pack.
Either your ISM is referencing the MDAC merge module or it's referencing another merge module that has a dependency on the MDAC merge module. Hence why I suggest a complete review.
Without looking at your application I can't give you a 100% answer but odds are that if you implement a setup condition (launch condition) to check for XP latest service pack or newer that you will likely work without installing a bunch of stuff you don't need to be installing.
Can someone give me a link where i can download a gtkmm 3.0 library for development without need to build it by myself?
thanks
http://live.gnome.org/gtkmm/MSWindows
That is the best I could find. It stops at 2.8, tough.
http://mail.gnome.org/archives/gtkmm-list/2011-April/msg00077.html
That is an email to the gtkmm mailing list from the windows installer developer. It seems that the dev doesn't have much time for it right now (or at least didn't on April 28, 2011).
Not much help, but that seems to be the state of gtk+ and gtkmm on windows right now.
The original question is old, but I post here for future visitors.
Apparently the link specified in senshikaze's answer is broken.
Windows installer (for both runtime and development stuff) is available from ftp.gnome.org
32-bit
64-bit
I built the gtkmm binaries over official gtk 3.6.4 binaries.
For 32 bit version you can download the binaries that I created, and there is also the (simple) procedure to create them yourself if you need 64 bit, everything on http://www.giuspen.com/2014/02/build-gtkmm-3-6-0-windows-binaries-on-official-gtk-3-6-4-bundle/
Gtk 3.0 library for windows is at hand from http://www.gtk.org/download/win32.php/
And you could find more optional dependence on http://win32builder.gnome.org/
But Gtkmm 3.0 hasn't have an official release, but some volunteer make it, I find a good one, http://sourceforge.net/projects/tview/files/gtkmm_bin_3_6.7z/download
I created a blog on how to install latest gtkmm on Windows (step by step) here:
http://gtkmm-installation.blogspot.com/
UPDATE:
I have just compiled everything with Visual Studio, You can download my gtkmm3 development binaries for Windows x64 from my GitHub page, I also made a wiki entry on how to compile everything on your own with Visual Studio.
All of the Visual Studio projects to compile everything can also be found on GitHub.
You can install it with vcpkg.
I've recently heard about Qt and read about how fun it is to develop with. By the way, I'm also buying a Nokia N900 and I heard that its operating system, Maemo 5, supports Qt quite nicely, so I thought I'll give it a shot.
I'm a .NET developer, so I'd prefer to develop on Windows, and if it is possible, using Visual Studio.
I downloaded the latest Qt SDK. I started up the Qt Creator and created a simple "Qt4 Gui Application". It was working fine, however, I couldn't find any options to compile for Maemo 5 anywhere.
Then, I downloaded the Visual Studio plugin and tried to create a "Qt Application" with that, however, no matter which Qt project type I chose, after clicking the OK button, the dialog just kept popping up again, so it couldn't create anything.
I also read about the Maemo 5 SDK, however, it only seems to work on Linux. (Every walkthrough for Windows started with setting up a virtual machine with Linux.) However, I'm not experienced with Linux at all, so I'd prefer to stay on Windows.
So my question is: is it possible to create Qt applications that will run on Maemo 5 while developing on Windows, or this is impossible?
Thank you in advance for any answers.
EDIT (Solution):
Since the time I started this question, a very nice development tool, the Nokia Qt SDK solves this problem very well. It is cross-platform and can be used to develop Symbian and Maemo apps alike. For the Maemo toolchain, it uses MADDE, which is exactly the tool recommended by the answer. (Note that it is no longer a technical preview anymore.)
Here is a very nice introduction video about the Nokia Qt SDK.
I would suggest getting used to Linux; after all, Maemo (or MeeGo, now) is really Linux underneath, and the official SDK is the Linux-based scratchbox.
That being said, there exists an unofficial community project MADDE:
This is a TECHNICAL PREVIEW of a new development tool for Maemo. MADDE stands for Maemo Application Development and Debugging Environment and offers the following features:
Command-line cross-compiling
Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
Configurable for different targets & toolchains
Client for the device to simplify the development process
Simplicity
You are welcome to test the tool in your development process. But keep in mind that this is a technical preview. We highly appreciate your feedback in talk, the developer list and especially in bugzilla (Developer Platform -> MADDE).
My google-fu has failed me - can MonoDevelop be used on Windows? Preferably without having to compile from source?
It works well on my home Ubuntu box, and while I have Visual Studio at work, it seems there might be some advantages to having MonoDevelop too.
EDIT: I'm aware of SharpDevelop; I'd prefer to have MonoDevelop if possible, just because I've started to get familiar with the interface, and I believe the SharpDevelop and MonoDevelop are not so closely related any more.
Woohoo! MonoDevelop for Windows is a supported download.
It seems that MonoDevelop on Windows still has a number of outstanding problems, even when built from source (and can only be built on .NET, not on Mono). So obviously there is no installer yet either.
The answer to my question then is No, MonoDevelop on Windows is not ready for normal use.
I guess I'll make do with Visual Studio and SharpDevelop on windows and wait patiently (or maybe even have a look at the outstanding bugs...!)
UPDATE: MonoDevelop for Windows now has a preview installer which can be downloaded here
MonoDevelop has official support for Windows since version 2.2:
Windows Support
Windows now Officially Supported
Windows is now an officially supported
platform for running MonoDevelop. Many
Windows specific issues have been
fixed, and some add-ins such as
debugging and subversion support have
been written specifically for Windows.
Windows Installer
We are releasing a new Windows
Installer which includes almost all
you need to run MonoDevelop. The only
external dependency is gtk#, which is
provided in a separate installer.
You can download the latest stable release.
Try SharpDevelop . MonoDevelop is built on SharpDevelop's code base.
There was a recent blog entry about MonoDevelop on Windows. Now is probably the time to try it out.
Update: MonoDevelop have just been released for Windows and Mac. More from Miguel's blog.
It's possible, but not easy. There's certainly not an installer.
This is pretty much the only guide to getting it to work:
http://lists.ximian.com/pipermail/monodevelop-list/2006-September/004442.html