First of I am on Mac OS Mavericks and I use XCode 5.
I'm making a chess application and I use SDL. I now want to have an additional window with some tables and buttons that will show data about the game and control the SDL Window.
Would it be practical and possible to make the control window with Cocoa, or would it be easier to make the control window with SDL as well? Having forms and buttons and tables seems impractical with SDL, but maybe I'm wrong. Performance is very important.
I have experience with the SDL library with C++. I don't think/know if it would even be compatible with iOS development. I would personally use Cocoa for the window and SDL for other stuff if possible.
Related
I plan to develop a mac OSX app that has a UI similar to that of iPhoto - a panel on the left and a grid view of images on the right. I am thinking of using NSSplitView to create two panels and using NSCollectionView for the grid.
I guess this must be a pretty popular and common UI pattern for mac apps. I am new to cocoa development. Can anyone with previous experience point me to any related cocoa code samples and design document?
Thanks a lot in advance.
N.B.
This missing piece here is an NSOutlineView in source list mode, put that in your left pane. But otherwise seems like a good place to start.
You might also be interested to see what the developer of Sonora approached this problem; although this is a music app the layout is almost the same.
Is the semi-transparant notification window which XCode 4 shows on Snow Leopard and on Lion a standard Cocoa control or is it something custom? I've seen more and more apps with similarly styled popups, and don't want to go about reinventing something if a much cleaner implementation exists in Cocoa. If this is a standard control, could someone tell me the name or point me to the documentation for it?
This is the popup window I am referring to:
This is custom but Matt Gemmell has sample code at http://mattgemmell.com/source. It's called RoundedFloatingPanel.
I need to display a full screen DirectX window from a Qt app.
Although directX isn't supported directly anymore by Qt this should be easy enough - just override QWidget, provide your own paintEvent() and set a WA_PaintOnScreen attribute.
But when the app is full screen DirectX is grabbing all the mouse and keyboard inputs - so the only way out of the app is ctrl-alt-del.
ps. Even if I wrote DirectX keyboard handlers I would still have to find a way of creating the correct Qkeypress event to pass to Qt.
Has anyone done this? Or is there a simple way to tell DirectX not to grab the keyboard?
To my knowledge Direct3D does not get the keyboard. Your problem more likely arises from the fact that Direct3D in full-screen is quite a different beast. Things like GDI (which Qt may well use to do rendering) do not work by default, the run-time hooks lots of bits of information. That info then, presumably, never manages to get to Qt. The options you have are to re-implement Qt to render using Direct3D (Lighthouse project?) or to use a pseudo full screen. This is usually done by creating a window that has a client area the same size as the screen and then positioning it correctly.
The latter would probably be the simplest solution ...
There was an attempt to get a D3DWidget kind of thing in Qt 4.3-4.5 or something like that, but it never was stabilized or approved and later even removed.
Perhaps indeed lighthouse is an option (with a medium sized amount of work, basically links OS/DX stuff to Qt stuff) or you can take a look at the old direct3D code in older Qt branches. I never used it, and it probably isn't intended to use with recent versions of Qt, but it's better than nothing.
The client for the MMO I work on uses two contexts, one for a window view and one fullscreen. I'm wondering if I just use a window sized to the display I can simply resize it if the user wants a smaller window so they can access their desktop.
Is their a performance penalty for running opengl in a window vs fullscreen assuming the same dimensions etc?
The client shell is written in cocoa; the game code itself is cross-platform.
We only support OSX 10.5 and 10.6 for the next release.
Before 10.6, if your context did not have the full screen flag in it's creation, then you had a small performance difference. Now, with 10.6, this has changed.
Have a look at:
http://lists.apple.com/archives/Cocoa-dev/2009/Sep/msg01054.html
if there is a cost associated with clipping each frame, then yes.
I want to build a desktop app where the size of both the window and the content is resized automaticly according to the resolution of the monitor. I know it can be done easily with the docking features of .NET Forms, but my customer insists on going with Linux so I can't use it.
I tried Flex & Air, but the content is not resized automaticaly when I put the app in fullscreen or in another resolution (the app goes full screen but I still have tiny buttons). Now, I am looking at Qt and Gtk...
Is there a GUI framework that can do that? I don't care about the programming language.
Also, since the app will go in a bar it would be nice to be able to customize easily the skin. (like in Flex, WPF, etc.)
Regards,
Pascal
An excellent place to start is understanding how the Screen class works: MSDN Even though that is .Net, it will give you an idea of how the screen size, dpi, etc. can be obtained. In addition that information should translate to the Mono platform. Since your client is insisting on Linux, you should look at MonoDevelop and then possibly the GTK# framework. My understanding is that GTK# is not a very friendly (that is pretty) development system (yet).
See:
MonoDevelop
GTK#