is there way to prevent application exit by clicking close button? the following code only hide minimize and maximize buttons but not close button...
Atom window_type = XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
long value = XInternAtom(display, "_NET_WM_WINDOW_TYPE_TOOLBAR", False);
XChangeProperty(display, window, window_type, XA_ATOM, 32, PropModeReplace, (unsigned char *) &value,1 );
i tried to search via google about overriding _NET_CLOSE_WINDOW but can't really find one... or a way to remove _NET_WM_ACTION_CLOSE from the xprop...
Read ICCCM & EWMH. You might need months (or years) to understand all the details (and the relation to X11 and X protocols and architectures).
You could in theory do what you want in raw Xlib. But details are so complex that you really should use some toolkit, like Qt or GTK (life is short), or maybe libSDL or SFML. See also this list.
Mastering X11 at the protocol and Xlib levels take a lot of time (the related documentation has many thousands of pages). Are you sure to willing to spend that?
So coding at the raw X11 level is like coding in assembler. Nobody does that for real programs today, and for similar reasons (too low level of abstraction; too many details to care about....).
Notice that the current trend is to replace X with Wayland. You could need several years to develop your thing from scratch in X11, and by the time you'll succeed, X would become obsolete. BTW recent versions of Qt & GTK know about Wayland (so the same code can work on X11 and on Wayland).
So use some GUI toolkit. They are monster software of millions of lines, and there is a reason for that complexity (also, graphics cards are very complex hardware today; see also this & this). They give you the ability to disable closing a window (because they know all the ICCCM & EWMH details).
Since you tagged your question with C++, I strongly recommend using Qt (or maybe SFML). The documentation of Qt is excellent.
BTW, your unclear question looks strange (and lacks motivation and context). It seems that you are wrongly supposing that your application is the only one on the screen, and that is against the philosophy of every windowing system (which are multi-tasking and multi-window, so multi-application, at heart). You should think your application as working with other ones (e.g. for copy & paste, which has no sense without thinking of several applications and several windows involved). And an advanced user could always "terminate" your application (e.g. with kill(1) or xkill). You probably want instead to be notified of window closes (e.g. to show some dialog when that happens). You should not even design an unclosable application (that is against all coding and interface guidelines).
Related
I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
In Windows XP the Win32 API renders the controls using GDI/GDI+.
Now I'm on 7, so if I use the API's functions, will the rendering automatically be handled by the DWM/WDDM (so by DirectX)? or will it continue to render with GDI?
Or likewise, will an old app written with WinAPI, be rendered with GDI also in Windows 7?
Thank you in advance for the help :)
In my experience, if the Aero display is on everything will render via that system, it just won't be obvious to your application. You'll still render in GDI, but it will be to a back buffer and not directly to the screen buffer (in fact it's more complicated then that). That way your older app can get the benefits of the new features, like the live preview effects, without having to be aware of them.
Really though, your application doesn't really notice a difference. The API is still the same API as before and works as you expect it. There are ways to take advantage of this, but you have to opt in to really use it.
If your application is written to use GDI, then it will continue to use GDI. The underlying implementation has changed quite a bit (as I recall, most hardware acceleration was removed in Vista, and put back in, in a new form, in Win7)
But it won't magically be transferred to Direct2D, no.
On performance front, it is the same old farce and as per usual 'Do Your Own Benchmarking' across OS-es. But, almost a decade old OS for anything GDI still slams Windows7 and plenty of apps will be incredibly more responsive on XP.. Sadness.. especially when you consider that translation of such an old API (as a compatible interface) should be trivial to any new driver or display tech.
Apparently some ops like blitting are supported but look at the result of your target 2D GDI app and judge for yourself..
Here are some observations, but please do your own for a dozen scenarios and compare, especially if it is GDI intensive like a million audio/video apps out there (no wonder iFruit boys are gaining share).
http://www.passmark.com/forum/showthread.php?t=2233
And while you will find all the typical and fluffy MSDN blog explanations that get 'technical' (ie. surface-style nonsense) the reason is very simple: buy a new OS, pull the carpet on old API and complicate it further by allowing new APIs to work with it (but not benefit the old one, easily doable by providing a new dll and .lib ).
For one history lesson and how hard it was to translate GDI calls to Direct2D or use libgdiplus from Mono and derive ideas etc, here is the propaganda:
http://blogs.msdn.com/directx/archive/2009/05/12/2d-drawing-apis-in-windows.aspx
I'm considering writing a new Windows GUI app, where one of the requirements is that the app must be very responsive, quick to load, and have a light memory footprint.
I've used WTL for previous apps I've built with this type of requirement, but as I use .NET all the time in my day job WTL is getting more and more painful to go back to. I'm not interested in using .NET for this app, as I still find the performance of larger .NET UIs lacking, but I am interested in using a better C++ framework for the UI - like Qt.
What I want to be sure of before starting is that I'm not going to regret this on the performance front.
So: Is Qt fast?
I'll try and qualify the question by examples of what I'd like to come close to matching: My current WTL app is Programmer's Notepad. The current version I'm working on weighs in at about 4mb of code for a 32-bit, release compiled version with a single language translation. On a modern fast PC it takes 1-3 seconds to load, which is important as people fire it up often to avoid IDEs etc. The memory footprint is usually 12-20 mb on 64-bit Win7 once you've been editing for a while. You can run the app non-stop, leave it minimized, whatever and it always jumps to attention instantly when you switch to it.
For the sake of argument let's say I want to port my WTL app to Qt for potential future cross-platform support and/or the much easier UI framework. I want to come close to if not match this level of performance with Qt.
Just chiming in with my experience in case you still haven't solved it or anyone else is looking for more experience. I've recently developed a pretty heavy (regular QGraphicsView, OpenGL QGraphicsView, QtSQL database access, ...) application with Qt 4.7 AND I'm also a stickler for performance. That includes startup performance of course, I like my applications to show up nearly instantly, so I spend quite a bit of time on that.
Speed: Fantastic, I have no complaints. My heavy app that needs to instantiate at least 100 widgets on startup alone (granted, a lot of those are QLabels) starts up in a split second (I don't notice any delay between doubleclicking and the window appearing).
Memory: This is the bad part, Qt with many subsystems in my experience does use a noticeable amount of memory. Then again this does count for the many subsystems usage, QtXML, QtOpenGL, QtSQL, QtSVG, you name it, I use it. My current application at startup manages to use about 50 MB but it starts up lightning fast and responds swiftly as well
Ease of programming / API: Qt is an absolute joy to use, from its containers to its widget classes to its modules. All the while making memory management easy (QObject) system and mantaining super performance. I've always written pure win32 before this and I wil never go back. For example, with the QtConcurrent classes I was able to change a method invocation from myMethod(arguments) to QtConcurrent::run(this, MyClass::myMethod, arguments)and with one single line a non-GUI heavy processing method was threaded. With a QFuture and QFutureWatcher I could monitor when the thread had ended (either with signals or just method checking). What ease of use! Very elegant design all around.
So in retrospect: very good performance (including app startup), quite high memory usage if many submodules are used, fantastic API and possibilities, cross-platform
Going native API is the most performant choice by definition - anything other than that is a wrapper around native API.
What exactly do you expect to be the performance bottleneck? Any strict numbers? Honestly, vague ,,very responsive, quick to load, and have a light memory footprint'' sounds like a requirement gathering bug to me. Performance is often overspecified.
To the point:
Qt's signal-slot mechanism is really fast. It's statically typed and translates with MOC to quite simple slot method calls.
Qt offers nice multithreading support, so that you can have responsive GUI in one thread and whatever else in other threads without much hassle. That might work.
Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.
JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.
I have installed the latest versions of Programmer's Notepad and JuffEd and studied the memory footprint of both editors by using Process Explorer.
Empty file:
- juffed.exe Private Bytes: 4,532K Virtual Size: 56,288K
- pn.exe Private Bytes: 6,316K Virtual Size: 57,268K
"wtl\Include\atlctrls.h" (264K, ~10.000 lines, scrolled from beginning to end a few times):
- juffed.exe Private Bytes: 7,964K Virtual Size: 62,640K
- pn.exe Private Bytes: 7,480K Virtual Size: 63,180K
after a select all (Ctrl-A), cut (Ctrl-X) and paste (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Virtual Size: 66,700K
- pn.exe Private Bytes: 8,580K Virtual Size: 63,712K
Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.
Combined exe and dll sizes:
- juffed.exe QtXml4.dll QtGui4.dll QtCore4.dll qscintilla2.dll mingwm10.dll libjuff.dll 14Mb
- pn.exe SciLexer.dll msvcr80.dll msvcp80.dll msvcm80.dll libexpat.dll ctagsnavigator.dll pnse.dll 4.77 Mb
The above comparison is not fair because JuffEd was not compiled with Visual Studio 2005, which should generate smaller binaries.
We have been using Qt for multiple years now, developing a good size UI application with various elements in the UI, including a 3D window. Whenever we hit a major slowdown in app performance it is usually our fault (we do a lot of database access) and not the UIs.
They have done a lot of work over the last years to speed up drawing (this is where most of the time is spent). In general unless you really do implement a kind of editor usually there is not a lot of time spent executing code inside the UI. It mostly waits on input from the user.
Qt is a very nice framework, but there is a performance penalty. This has mostly to do with painting. Qt uses its own renderer for painting everything - text, rectangles, you name it... To the underlying window system every Qt application looks like a single window with a big bitmap inside. No nested windows, no nothing. This is good for flicker-free rendering and maximum control over the painting, but this comes at the price of completely forgoing any possibility for hardware acceleration. Hardware acceleration is still noticeable nowadays, e.g. when filling large rectangles in a single color, as is often the case in windowing systems.
That said, Qt is "fast enough" in almost all cases.
I mostly notice slowness when running on a Macbook whose CPU fan is very sensitive and will come to life after only a few seconds of moderate CPU activity. Using the mouse to scroll around in a Qt application loads the CPU a lot more than scrolling around in a native application. The same goes for resizing windows.
As I said, Qt is fast enough but if increased battery draining matters to you, or if you care about very smooth window resizing, then you don't have much choice besides going native.
Since you seem to consider a 3 second application startup "fast", it doesn't sound like you would care at all about Qt's performance, though. I would consider 3 second startup dog-slow, but opinions on that vary naturally.
The overall program performance will of course be up to you, but I don't think that you have to worry about the UI. Thanks to the graphics scene and OpenGL support you can do fast 2D/3D graphics too.
Last but not least, an example from my own experience:
Using Qt on Linux/Embedded XP machine with 128 MB of Ram. Windows uses MFC, Linux uses Qt. Custom user GUI with lots of painting, and a regular admin GUI with controls/widgets. From a user's point of view, Qt is as fast as MFC. Note: it was a full screen program that could not be minimized.
Edited after you have added more info:
you can expect a larger executable size (especially with Qt MinGW) and more memory usage. In your case, try playing with one of the IDEs (e.g. Qt Creator) or text editors written in Qt and see what you think.
I personally would choose Qt as I've never seen any performance hit for using it. That said, you can get a little closer to native with wxWidgets and still have a cross-platform app. You'll never be quite as fast as straight Win32 or MFC (and family) but you gain a multi-platform audience. So the question for you is, is this worth a small trade-off?
My experience is mostly with MFC, and more recently with C#. MFC is pretty close to the bare metal so unless you define a ton of data structure, it should be pretty quick.
For graphics painting, I always find it useful to render to a memory bitmap, and then blt that to the screen. It looks faster, and it may even be faster, because it's not worrying about clipping.
There usually is some kind of performance problem that creeps in, in spite of my trying to avoid it. I use a very simple way to find these problems: just wait until it's being subjectively slow, pause it, and examine the call stack. I do this a number of times - 10 is usually more than enough. It's a poor man's profiler but works well, no fuss, no bother. The problem is always something no one could have guessed, and usually easy to fix. This is why it works.
If there are dialogs of any complexity, I use my own technique, Dynamic Dialogs, because I'm spoiled. They are not for the faint-of-heart, but are very flexible and perform nicely.
I once made an app to determine the "primeness" of a number (whether it was prime or composite).
I first attempted a Qt GUI, and it took 5 hours to return the answer for 1,299,827 on a computer with 8GB of RAM and an AMD 1090T # 4GHz running no other foreground processes under Linux.
My second attempt used a QProcess of a console application that used the exact same code. On a laptop with 1.3GB of RAM and a 1.4GHz CPU, the response came with no perceivable delay.
I will not deny, though, that it is far easier than GTK+ or Win32, and it handles things quite nicely, but separate intensive processing ENTIRELY from the GUI if you use it.
In Windows when you create a window, you must define a (c++)
LRESULT CALLBACK message_proc(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam);
to handle all the messages sent from the OS to the window, like keypresses and such.
Im looking to do some reading on how the same system works in Linux. Maybe it is because I fall a bit short on the terminology but I fail to find anything on this through google (although Im sure there must be plenty!).
Is it still just one single C function that handles all the communication?
Does the function definition differ on different WMs (Gnome, KDE) or is it handled on a lower level in the OS?
Edit: Ive looked into tools like QT and WxWidgets, but those frameworks seems to be geared more towards developing GUI extensive applications. Im rather looking for a way to create a basic window (restrict resize, borders/decorations) for my OGL graphics and retrieve input on more than one platform. And according to my initial research, this kind of function is the only way to retrieve that input.
What would be the best route? Reading up, learning and then use QT or WxWidgets? Or learning how the systems work and implement those few basic features I want myself?
Well at the very basic level you have the X Window protocol http://en.wikipedia.org/wiki/X_Window_System_core_protocol, which we can be pretty complex to handle if you want to do any application. Next on the stack there's Xlib http://en.wikipedia.org/wiki/Xlib which is a "convenient" wrapper around the X protocol, but still is complex for "real life" applications. It's on top of Xlib that most other frameworks are built, trying to simplify application development. The most know are: Xt, Gtk, Qt, etc.
Like in window you have a "event loop", and if you want you can implement on top of it a GetMessage/DispachMessage metaphor to mimic the windows behavior. That way you may have a WNDPROC, but natively X doesn't provide such thing.
Before reinventing the wheel is preferable to take a look at similar applications, what they are using.
If you need something simple you can try SDL http://www.libsdl.org/, which is a cross platform library to aimed to develop games/simple applications. Another alternative is Allegro game library http://www.talula.demon.co.uk/allegro/.
In principle it is absolutely the same. However, it has nothing to do with communication with the OS (nor does it on win32, using user32.dll is entirely optional)
A GUI application has an event loop somewhere, which processes messages from a queue at some level.
There are a lot of libraries typically used to "hide" this behaviour - you can use them (and indeed, you should). If anything, the Xlib event system is even more perverse than Win32's user32.dll one, and is less widely understood, therefore fewer people use it directly.
In Linux or in Windows, applications can use the low-level GUI, or can use a library. Most use a library. Applications can also choose to do neither and operate without a GUI (server applications typically do this). Applications can create multiple threads, one of which sits in an event loop, and others work differently. This is a popular approach too.
Most GUI applications use a higher level library for their GUI
Non-interactive applications, e.g. server applications, don't use the GUI at all and don't use the libraries (e.g. XLib, user32.dll)
Applications which don't lend themselves to an "Event loop" (e.g. Games) typically use a separate thread to process their event loop.
These things are largely true on Win32 and Linux.
It's totally and utterly different. That window procedure is 100% specific to the Windows OS. For linux, it will depend on the window manager (gnome, kde - as you've already mentioned). If you wish to do cross-platform development, you might want to look at things like QT.
You may wish to take a look at the following URLs:
http://www.qtsoftware.com/products/appdev
http://en.wikipedia.org/wiki/Qt_toolkit
As stated by xhantt, what transport the equivalent messages you are looking for is the X Window System. Which, indeed, can be a bit complex.
With XLib you will need to handle the events registering and dequeuing in your main loop. See the XLib manual for a complete description on how to proceed. But don't forget that you will only catch window and inputs events this way. Not every OS messages.
You can also look for XCB which is a newer, and probably easier, library.
If you build your application on top of those two library, it will run smoothly under (almost, we can never be too sure) every WM. And you won't require any dependency that most linux user don't already have on their installation. If you go with Qt, GTK, etc... It will be easier and work under any WM, but they may not have library installed.