I have been working on a simple GUI and have hit a roadblock. I haven't found any examples or even readable source on how to create a GUI layout manager. I was wondering if anyone knew of some resources on creating one, or some source code that isn't cryptic like Qt's layout engine.
It depends on what you mean by "layout manager", and I'm not familiar with Qt, so that doesn't give me much of a clue.
If you mean things like resizable window handling, though, I think the relevant term is "constraint solver". I've never looked into it that much, but I believe GUI constraint solvers are based on linear programming - the Simplex algorithm and all that. It might be possible to do something with Gaussian Elimination, but I'm far from confident about that.
Based on a quick search for "gui layout linear programming", you might find this paper from CiteSeerX interesting - there's a PDF download. If you don't like cryptic, well, at a glance at least it's not exactly math heavy, but I suspect it's not light reading either. I guess I'll find out shortly, as you've got me interested.
I am currently making a Windows port for Mozilla XUL. My approach does not involve linear programming techniques like Steve mentioned, but it is a more object oriented approach. It is based on the Composite and Decorator design patterns.
The composite pattern allows you to create controls that have child controls, which in turn can have their own children. A control is responsible for positioning its child controls within its designated client rectangle.
For example suppose you want to implement a layout that positions its child controls horizontally. The layout algorithm then needs to calculate the width of each child control in order calculate the x offsets for each child control.
Calculating the width of a container is done by returning the sum of the widths of the child controls.
The Decorator classes can be used to add extra properties. For example a MarginDecorator can add spacing between child controls, a ScrollDecorator can scrollbars, etc...
It's a fun thing to do, I wish you good luck!
Related
I have a really simple question, but I'm not sure what the correct way is to approach it.
I'm working on a Win32 API application (in C++) and I'd like to put buttons right beside each other, just like this example in PhotoShop:
My first idea is to parent all buttons in a container and then calculate the offset based on the size of the buttons. This seems simple, but I'm not sure if it's the way normal people do it.
My second idea is just a concept. Since I'm used to Android programming, I was hoping that there were pre-built layout methods, such as constraint layouts or frame layouts. I've done research, but haven't seen this, so I guess it's not possible, correct?
As a hobby, I've been working on remaking an old video game, and I want to avoid reinventing the wheel where possible. The game is heavily GUI-based, but the GUI needs to be customized in terms of look-and-feel, and also needs to work with 3D OpenGL rendering for a few game screens.
To give you an idea, here's a screenshot from the initial prototype:
There's a lot of animation used, and 3D also, but the GUI widgets behave much the same as in a standard desktop application.
Thus far, I've been using my own GUI library (it's not robust or complete, and I've been running into some problems).
I've been considering migrating to Qt given it's reputation and impressive features, and some of the nice screenshots on the Qt website. But I've never used Qt before, so I don't really have an idea of what it's capable of, or what kind of time investment would be required to learn it. (Note I've used FLTK).
My question is: would it be possible / practical to use Qt in this situation?
UPDATE: After mocking up some game screens in Qt, I've decided not to use it. While it supports many of the features I need out-of-the-box (particularly through Style Sheets), I need to support custom bitmap-based pre-rendered fonts (I can't convert/replace them). And I can't subclass QFont, or reimplement it without it breaking in future Qt releases. That said, I was extremely impressed with Qt (both in its ease of use, and good documentation). I will be borrowing some of its features for my own engine. Thank you to all who provided input.
It's hard to know everything your game needs to do based on a screenshot; however, I will echo the sentiments of other posters here and provide a couple of avenues for you to look at.
One, is that you might want to consider QtQuick over the GraphicsView Framework, but this REALLY depends on what you need to do. I just want to throw it out there as an alternative so you don't miss it. This tutorial uses QtQuick to put together a really slick looking connect four style game. This may be more simplistic than what you want to go for, but then again, maybe it isn't, it depends on what you need to do.
Second, before writing custom paint events for all of your buttons, I would consider using Qt Style Sheets and style your widgets in a CSS like syntax. This will allow you to change the look and feel of your GUI in a very flexible way really quickly. Based on your screenshot, I think you can get what you want out of style sheets much faster than subclassing and rolling your own setup. But once again, it's hard to know based on one screenshot. Here's an example of a dark and orange GUI that was implemented using only Qt Style Sheets. The border-radius property of QPushButton's style sheet would give you the rounded buttons (ref).
The simple answer has been given above but to throw some more thoughts in: yes it's possible, you probably won't need to fight against Qt too much. For the most part the recommended advice for going to heavily customised widgets like that is subclass and implemented the paint event yourself.
You can then use a load of basic drawing primitives to get the basic shapes for the elements and expand from there. There's actually a couple of questions on here with really good resources about how to do it.
I'm using QT creator and have all my methods etc designed and trying to design a UI and I'm not sure what widget I should be using to reference my puzzle layout.
I've been reading over the documentation for a while and I still am nowhere closer to finding a solution to what I should be using to display my values. I know what I should like but all I seem to find information on is various layouts of entry boxes that are in no way linked. I have no problem with coding it myself to communicate with my classes if I just knew what to use to start off with.
I need something that can help me create a layout that has up to two numbers with positions specific to the type of hint it is with a slash between the hints, black blocks that are neither hints nor stored values and squares that have values that can take up the whole square.
Layout is something similar to http://www.nikoli.co.jp/en/puzzles/kakuro/
I wish I knew what to pick >.<
Personally I'd use QGraphicsView and handle the drawing myself.
It can draw rectangles, triangles, circles and text without much effort, and that's pretty much everything you need as far as I can see. You just need to add the objects to a QGraphicsScene and you get them on the screen. You can also interact with the objects (you can find which object you're pointing at etc.)
In my project I going to generate a user interface through programming. Scalability of this UI is very important requirement.
So far I am using two dimensional graphics for generating the UI.
I think there may be different solutions but for the moment I know only two.
First one is supplying X,Y coordinates of each two dimensional graphic on my UI.(I do not prefer this solution because I do not want to calculate X,Y coordinates of each graphic. For the moment I don't have a logic for doing this easily)
Second one (which is currently I am using now) is using layouts which organizes its contents according to size of item. In this solution I don't have to calculate X,Y coordinates of each item. (Layout is doing this for me.) But this approach may have its own pitfalls.
I am very new to user interface programming. Can you give me advice about this issue?
The general rule I follow is that you should always use layout containers unless you have very specific reasons to use an absolute layout. The only real times I use absolute layouts is when I'm implementing a weird custom layout that doesn't fit easily with built in layout managers.
Layout managers will make your life much easier. Handling resizing windows or variably sized content is made significantly easier with layout managers.
I can't remember every having a problem with qt's built in layout stuff.
I am assuming you rail map only needs to be a schematic of the real track layout, you could create components that are all layed out on a grid, and for each grid cell you implement a simple layout algorithm, depending on your requirements you could just state that one grid cell can only have one actual control on it (and make the cells smaller) or for larger cells you have fixed spots for each type of control, or just arrange the controls within a cell from left to right/top to bottom, whatever works for you. You could also subdivide the cells themselves into subcells to constrain the controls. So that when you scale the whole, each cell can then tell the control what size it should be.
It might also help to implement things as layers on your display, for example make the track layer separate from the control layer.
You are working on a very specific "non-traditional" ui you will need some solutions that fit your problem.
I don't know if you are doing this already, but think if you can implement a data driven approach for the configuration of your UI. Don't hardcode the layout, separate the layout functionality from the actual operational parts and move them into a file that can easily be changed.
It sounds you have some kind of working solution but you said "I do not prefer this solution because I do not want to calculate X,Y coordinates of each graphic", if you have graphical controls that can be placed anywhere on the screen though code, it is probably not a big step to have an editor where a user can place these controls. It might not be as much effort as you think, especially if you are already using a configuration file for your UI instead of hardcoded values.
I have recently done a lot of work changing the normal look of qt elements through styles, but I don't think that the normal qt-gui parts will be enough for your endeavor, but the QGraphicsView subsytem would probably be a good fit it does scales well and handle interactions with large number of elements well, but it is hard to give you a more specific answer without knowing more details
There is Qt Designer (GUI Builder) which allows designing GUI like in Visual Studio.
Calculating X,Y by hand is a bad approach - it is absolutely inscalable.
Don't reinvent the wheel:
Inherit your objects from UI objects e.g. panels so you could use the UI techniques from those objects.
For the rest use containers or any other layout objects
I am exploring a possibility to write a kind of a notebook analogue that would reproduce the look and feel of using a traditional notebook, but with the added benefit of customizing the page in ways you can't do on paper - ask the program to lay ruled paper here, grid paper there, paste an image, insert a recording from the built-in camera, try to do handwriting recognition on the tablet input, insert some latex for neat formulas and so on. I'm pretty interested in developing it just to see if writing notes on computer can come anywhere close to the comfort plain paper + pencil offer (hard to do IMO) and can always turn it in as a university C++ project, so double gain there.
Coming from the type of project there are certain requirements for the user interface:
the user will be able to zoom, move and rotate the notebook as he wishes and I think it's pretty sensible delegate it to OpenGL, so the prospective GUI needs to work well with OGL (preferably being rendered in it)
the interface should be navigable with as little of keyboard input as user wishes (incorporating some sort of gestures maybe) up to limiting the keyboard keys as modifiers to the pen movements and taps; this includes tablet and possible multitouch support
the interface should keep out of the way where not needed and come up where needed and be easily layerable
the notebook sheet itself will be a container for objects representing the notebook blurbs, so it would be nice if the GUI would be able to overlay some frames over the exact parts of the OpenGL-drawn sheet to signify what can be done with given part (like moving, rotating, deleting, copying, editing etc.) and it's extents
In terms of interface it's probably going to end up similar to Alias' Sketch Book Pro:
picture.
As far as toolkits go I'm considering Qt and nui, but I'm not really aware how well would they match up the requirements and how well would they handle such an application.
As far as I know you can somehow coerce Qt into doing widget drawing with OpenGL, but on the other hand I heard voices it's slot-signal framework isn't exactly optimal and requires it's own preprocessor and I don't know how hard would be to do all the custom widgets I would need (say color-wheel, ruler, blurb frames, blurb selection, tablet-targeted pop-up menu etc.) in the constraints of Qt. Also quite a few Qt programs I've had on my machine seemed really sluggish, but it may be attributed to me having old PC or programmers using Qt suboptimally rather to the framework itself.
As for nui (http://www.libnui.net/) I know it's also cross-platform and all of the basic things you would require of a GUI toolkit and what is the biggest plus it is OpenGL-enabled from the start, but I don't know how it is with custom widgets and other facets and it certainly has smaller userbase and less elaborate documentation than Qt.
The question goes as this:
Does any of these toolkits fulfill (preferably all of) the requirements or there is a well fitting toolkit I haven't come across or maybe I should just roll up my sleeves, get SFML (or maybe Clutter would be more suited to this?) and something like FastDelegates or libsigc++ and program the GUI framework from the ground up myself?
I would be very glad if anyone had experience with a similar GUI project and can offer some comments on how well these toolkits hold up or is it worthwhile to pursue own GUI toolkit in this case.
Sorry for longwindedness, duh.
Have you tried FLTK? It is made with 3D graphics programming in mind and has interfaces to OpenGL. I wrote some FLTK->Scheme bindings and found the API to be real fun to work with.
OpenGL font support is terrible, in my experience. It sounds like you're going to have to develop all your own custom widgets anyway so don't even bother with a toolkit. You'll spend more time learning the toolkit, trying to figure out how to get that toolkit to work with OpenGL, and and trying to figure out how to make your special widgets in that toolkit than you will just rolling your own. I wouldn't give this advice in just any situation but it sounds like your application and your widget set is going to be very unique. Make a superclass for all widgets, define a draw method, even handler methods, etc., for override, and you've already done most of what those frameworks would do for you.
Also I'm sure you know this but this is an enormous project so you should initially narrow it down to a few simple objectives for a first iteration.