Similar to this question about GTK+ 3 for Windows, is there any place that offers compiled GTK# bindings for Windows? I searched for a while and can't find any official releases (which makes sense since there are no official GTK3 releases for Windows either), but also neither Banshee nor Xamarin come with GTK(#)-3.
I'm also unsure if these instructions for compiling GTK# 2 on Windows are still valid, but the page doesn't provide an awful lot of detail, so I guess it'll take half a day to figure out of it works that way.
Any other place where I might find the GTK# 3 binaries for Windows?
You can get the c# binding for GTK3 from:
https://github.com/mono/gtk-sharp/releases
This includes a windows installer.
These bindings are pre release and are versioned as Gtk# 2.99.3
My understanding is that the version will change to 3.0 when it is released as stable.
Related
Note: I just wanna say at first that I tried literally everything I could find about the subject (MSDN, Stack Overflow, D3DCoder, etc.) without any success (after solving one, another error was waiting for me). So I am posting here by pure demotivation (there are similar posts already, yes, but none of them actually helped me out).
Here is how it goes:
A few months ago, I decided to start learning modern OpenGL by pure curiosity, and finally decided to switch to DirectX after reading the downsides of OpenGL (I was also only targeting Windows platform). I think it was one of the worst move I ever made: I heard that OpenGL was lacking of documentation and everything was a mess with third party libraries, but I realized that DirectX was way worst than what it seemed to be compared to OpenGL. In fact, trying to code in modern DirectX 11 using Windows 7 and VS2013 is just a pain (especially shaders) and the time it takes to figure it all out is just a time waster. After reading a lot of porting articles on MSDN about alternative libraries, like DirectXTK, DirectXTex, DirectXMesh, Effects11 and DXUT, I still don't know what to do and how to setup a fully working modern project in Windows 7. Specifically, the 5 (/5_0) shader model (deprecated) combined with the new Effects11 library (not deprecated) is the thing that confuse me the most.
By the way, I am currently reading the latest Frank Luna book about the subject ('Introduction to 3D Game Programming with Direct3D 11') and I still can't get his samples working at all (even with DirectX SDK). Also, I don't know if what I am learning is relevant or not since he wrote it before the Windows SDK switch. For your information, the latest error I am trying to solve with his samples (for those who know the book) is a E_NOINTERFACE from D3DX11CreateEffectFromMemory function (at runtime):
HR(D3DX11CreateEffectFromMemory(compiledShader->GetBufferPointer(), compiledShader- >GetBufferSize(),
0, md3dDevice, &mFX));
// Done with compiled shader.
ReleaseCOM(compiledShader); -> crash here
All that being said, here is what I wanna know:
Are there any clear step-by-step tutorials on how to setup a modern DirectX 11 project in Windows 7 using VS2013 or it is still in pre-alpha stage (just kidding)?
What is actually going on with the shader model, the HLSL compiler, and the .fx files and what should be used (I hear everywhere that it is deprecated but no replacement seems to exist yet)?
For those who know the book, any idea on how to build the old DirectX SDK samples without getting this silly runtime error?
Thanks a lot!
E_NOINTERFACE is an usual error in that context, so likely there's something wrong with the code around it you are not showing in your question.
You can still use the legacy DirectX SDK with VS 2013, but it takes a slightly different procedure than was used with VS 2010. In VC++ Directories set Executable to $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86 or $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86, Include to $(IncludePath);$(DXSDK_DIR)Include, and Library to $(LibraryPath);$(DXSDK_DIR)Lib\x86 or $(LibraryPath);$(DXSDK_DIR)Lib\x64. Read MSDN for some other details of doing this. I've also made some notes w.r.t. to that book here.
You actually don't need the legacy DirectX SDK, but you may find it easier to do that for now using that book. VS 2013 comes with the Windows 8.1 SDK that has all the OS headers for DirectX 11 along with D3DCompile #47.
You can use the Direct3D tutorial for a simple example of setting up a Win32 desktop app (i.e. one that works on Windows 7) with a device, swapchain, and window. This makes no use of legacy DirectX SDK.
There are some additional Effects Tutorial Win32 Sample you can use as well. Instructions on adding the Effects 11 library is on the CodePlex wiki under Documentation / Effects 11 / Adding to a VS solution.
Your questions about FX vs. not are also covered on the CodePlex: Is Effects 11 deprecated? and How do I avoid using fx_5_0?. Also on StackOverflow.
Many of the older DirectX SDK samples have been reposted to MSDN Code Gallery and do not require the legacy DirectX SDK to build. You should read these posts for the fate of various DirectX SDK things:
DirectX SDK Samples Catalog
DirectX SDK Tools Catalog
Living without D3DX
DirectX SDKs of a certain age
The story for learning DirectX 11 with Windows Store apps / Windows phone 8.x aps is a lot cleaner, and is well supported by VS templates and MSDN documentation. Win32 desktop apps are of course a completely reasonable option, but you have to distinguish between legacy and modern with a bit of research. You still start with the standard Win32 desktop app project template in VS.
Note: Windows by default only supports OpenGL v1.5 software renderer. You have to install 3rd party ICD to get anything else, and there are no OpenGL VS templates.
My application requires a GUI, and I was thinking of using GTK+ because by far it is the best library for Graphical User Interface. When I looked at the GTK+ page and went to Language Bindings, I found the following:
If Ruby is a good language and has a lot of programmers, why doesn't Ruby support GTK+ 2.14 and newer versions?
Because bindings to a more recent versions hasn't been yet written ? ;-)
Ruby-GNOME project is probably the most known implementation, see status of Gtk2. They also provide bindings for Gtk3, version 3.4 .
The differences between 2.12 and 2.24 are relatively marginal, there is no point it should you keep back at writing Gtk2 UIs in Ruby. The project is very active, latest commits was done a day ago.
Btw. linking on Linux/BSD systems is done to the major version so it'll run regardless minor subversion is currently installed. If there is some very specific feature added in latest versions you can write binding yourself, it's very easy. However as you are just at learning stage I'd bet you'll ever get in such situation in the near future.
I've been using Qt for several months now with no problems. I originally downloaded the Qt 4.8 library with the most recent Qt Creator as of summer 2012, and I was able to start constructing my application. My application has demanding graphics needs, so I've been using the great windowing context Qt provides for OpenGL.
I've been slowly building my skills. I have explored programable shaders with success, and I wanted to leverage the power of Geometry Shaders. I am running OS X 10.7.5 on a MacBookPro6,2 with a GeForce GT 330M GPU. According to what I've read from others here, the upgrade to OS X Lion included a driver to run this GPU under the OpenGL 3.2 Core Specification, including support for programable Geometry Shaders. I also read here that while Qt 4.8 did not support OpenGL 3.2 on OS X, this support was included in their recent release of Qt 5.
I saw that Digia had also released an update to Qt Creator, so (being a little too excited for this potential breakthrough in my work) I uninstalled Qt and downloaded the Qt 5.0.0 library + Qt Creator 2.6.1. I went through the steps in the wizard, started up the new Qt Creator and now nothing works, haha. I have developed a love-hate relationship with my compiler and the cryptic messages it gives me, but this is different. The errors that are being thrown make it sound like it doesn't know how to read the code any more (just to pick one example out of several hundred errors "#include "). The wizard installed Qt fine, and all the guts are there, but I think the link to my gcc compiler has somehow been broken. Not even the examples that came with Qt 5 compile.
Qt has introduced a new "kit" paradigm to make developing on multiple platforms easier, and I have made efforts to change the setup of the kit. Qt detects several gcc compiler options, which I have tried, and I have manually pointed it to the path I get from the terminal command:
which gcc
/usr/bin/gcc
It appears to be gcc 4.2. I see that the most current version is gcc 4.7, but I have the most up-to-date version XCode provides. I also downloaded "Command Line Tools" from XCode and restarted, but it did not remedy my problems as magically as I had hoped. I am trying to update gcc manually, but I'm running into issues because it is asking me to update gmp and mpfr as well, and they are not fully cooperating.
Since the kit paradigm allows multiple libraries to co-exist in Qt, I re-downloaded the Qt 4.8 library, but it suffers from the same problem. I have pointed Qt Creator to qmake for both the 4.8 and 5.0 libraries, but that doesn't seem to be the problem either.
I haven't been able to see evidence of anyone else running into such a crippling problem, so that suggests that I am missing something simple. But even for being a newbie last summer, I felt I had gotten pretty comfortable with Qt, C++, and OpenGL from what I have managed to piece together from the Internet.
If anyone can nudge me in the right direction, I would greatly appreciate it. I am willing to rebuild my application from scratch in Qt 5.0, but I can't use Qt at all at the moment.
I finally got it to work! In the directory /usr/bin/ there was more than one g++ executable. They were labeled with different version numbers (g++-4.0, g++-4.2), but they showed up in Qt's automatic detection. All I needed to do was delete the extras. Leave only the g++ executable that is not labeled with a version number. By limiting the options available to Qt, it automatically selected a compiler and now it works.
It is embarrassing that it took so long for me to find such a fast solution, but it is still a relief. I hope others save time from my experience.
I have found plenty of articles and how-tos online about making plugins for Photoshop on a Mac. Trouble is, many are old, apply only to CS1/2/3/4, or refer to tools or APIs that (it appears) are obsolete. Some articles say you must use CodeWarrior, but it seems this no longer even exists in the Mac programming realm.
Today, in 2011, making plugins only for CS5 and only on a Mac running Snow Leopard, what is the proper toolchain and what libraries/APIs/frameworks should I be using?
I've gotten the impression that Carbon (whatever exactly that is) is old and to be avoided, but it's not clear if that's true for plugins. I am not clear as to whether I should use Cocoa (whatever that is) or not. I do think I will need Core Foundation (whatever...) Is there a choice about 64 vs. 32 bit or is CS5 purely 64 bit and that's that? (I prefer 64 bit, of course.) I do have the Photoshop CS5 SDK, and Photoshop CS5 itself installed.
Can XCode can be used as an IDE? I'll hand-code a makefile and compile at the command line, if that's easier or the only way possible. If XCode can be used, which project template to use? What is this "Mach-O" I read about, and how does that apply to PS plugins?
It's especially confusing since I'm a total noob at Mac programming of any kind, though many years experienced on Linux and other platforms.
Mission accomplished! (Months ago.. I just realized I had this question sitting here.)
Cocoa is useful for GUI settings windows and other things - it's a huge gob of stuff - but I ended up using it only for the "About" popup window for my plugin.
Completely forget about Carbon for the combination of CS5 or later, OSX 10.6 or later, and 64 bit. Apparently parts of Carbon had been made 64 bit in the past, but should be ignored now.
XCode is a fine editor. Start with a "dylib" project using C. C++ and Obj-C source files can be added without any fuss. There's no way getting around just needing to use XCode for some simple toy projects to gain familiarity with how it organizes things and builds apps and libraries. This is the only real "tool" needed; the rest is APIs - header files and libraries (or "frameworks" in the Apple world). While toying with XCode, get to know what a "bundle" is - a folder containing the executable and other files needed by the app.
Paths need to be set up to the Photoshop CS5 API, there being two or three specific directories to be listed. You may need to copy certain common source files out of the Photoshop example plugins directory, and there was a bit of trouble with a file named MachOMacrezXcode.h about which see What is the meaning of exit code 3 from Rez?
Unfortunately there were no truly useful examples of well-written plugins for CS5 on 64-bit. A combination of the Dissolve example, the SimpleFormat file read/write plugin, browsing source for plugins at http://www.telegraphics.com.au/sw/product/FilterFoundry and asking questions on the Adobe Photoshop SDK forum.
Pay no attention to the clumsy process of using some "Plugin Suite" for obtaining memory. It's like Microsoft's old 16-bit Windows API where you needed "memory handles" and thick malarky that is now several times obsolete. These days, good ol' malloc/free or new/delete are fine.
With all the arrowhead wounds I now have in my back, maybe I should write a book or something...
I need to support Windows 98. The Qt documentation claims this is possible, but there are no instructions. The distributed binaries of Qt 4.6 don't run on Win98 and the majority of Qt applications I have sampled also don't. For several apps that do run on 98, I have asked authors how they did it, but the common answer is that it was accidental and they don't know what factors caused it.
In searching the forums for help, I found only guesses that turned out to be wrong. For example, one belief is that to compile for Win9x, you must build the tools and the apps on that platform. Yet, things I found to run were built on newer versions of Windows.
What is required to build the Qt dev tools and then applications for Win98?
How about cross-compiling from WinXP or Linux?
Are there specific components that can't be made to run on Win98?
Are there particular difficulties with dynamic or static linking for Win98 support?
Here is as far as I'm going to get on this:
You can target Windows 98 using MinGW or VC++ 6 SP5 from any Windows version. Cross-compiling from Linux is doable but not easy to set up.
Qt 4.4.3 was the last version officially tested on Win98. To run the distributed binaries on Win98, you need to install older versions of glu32.dll and opengl32.dll that are available from Microsoft. Due to an unresolved bug, Assistant will launch but can't load the help files. The alternate version in the bin directory, assistant_adp.exe, works fine. It seems the only other potential problem is that QtOpenGL may use features not available on older boxes.
Qt 4.5.3 appears to be still compatible except for WebKit, OpenGL, and Phonon. QtOpenGL expects OpenGL 1.5, which I don't know is even possible on older boxes. I didn't look into Phonon deeply enough to see exactly what the problems are. QtWebKit now requires Win2K or better. The distributed binaries work mostly OK. Assistant depends on QtWebKit, so will not launch, but assistant_adp.exe still works.
Qt 4.6.3 distributed binaries are now completely incompatible with Win98. It may be possible to get some things working with MinGW 4.4 and a lot of hacking.
Building Qt Creator requires Qt 4.6.0 and either MinGW 4.4 or VS 2008.
Wow...interesting mission.
So, basically - yes, there is windows 98 support for Qt. The problem is that there is one big IF. For example if you even try to set some different QTextCodec::codecForName, you'll have to provide 3rd party ttf for this purpose, because in most cases Win98 will not recognize it as valid. If you provide the exact error, while compiling it on win98 machine, I could help you.
"How about cross-compiling from WinXP or Linux?" - If you use ONLY Qt libraries everything goes fine. Otherwise in .pro file, you have to link these libs under win32 and unix conditions. So you could even forbid your code, to be compiled and executed in other systems...
"Are there specific components that can't be made to run on Win98?" - Of course. In .pro file you could include different libraries, for different operating systems.
"Are there particular difficulties with dynamic or static linking for Win98 support?" - As far as I know - there isn't.
//off - But it still strange, that someone want to write application for win98, today...