I just want to know more about cross-platfrom programming. I create game in SFML 2.1 and C++. And I have a problem. This code works under Linux, but it doesn't work under Windows (MinGW). There is no error, but nothing is drawn.
Shop::Shop(): shop_texts() {}
//...
void Shop::draw(App* app)
{
app->window.draw(shop_texts.getText("btn_playerskins"));
}
shop_texts returns an sf::Drawable object.
And then in App:
shop.draw(this);
shop_texts exists, because I can check e.g position or text (this object contains sf::Text field). What is difference?
Related
I'm on Qt 5.9.1.
I'm trying to make an application accessible through screen readers. I have a custom widget (let's call it MyWidget) that contains text (a lot of it.) The text is drawn using QPainter, which is why a custom widget is used rather than something like QTextBrowser.
I implemented the QAccessibleTextInterface for the widget in a AccessibleMyWidget class that derives from QAccessibleWidget and QAccessibleTextInterface. It works fine with Orca under Linux, but when used in Windows 7 with NVDA, QAccessibleInterface::interface_cast() requests the wrong interface type. With Orca, I get requests for a QAccessible::TextInterface. In NVDA, it's always QAccessible::ValueInterface.
AccessibleMyWidget is defined as:
class AccessibleMyWidget:
public QAccessibleWidget, public QAccessibleTextInterface {
public:
explicit AccessibleMyWidget(QWidget* w)
: QAccessibleWidget(w, QAccessible::EditableText)
{
Q_ASSERT(isValid());
}
void* interface_cast(QAccessible::InterfaceType t) override
{
if (t == QAccessible::TextInterface) {
// !!! This is never requested with NVDA !!!
return static_cast<QAccessibleTextInterface*>(this);
}
return QAccessibleWidget::interface_cast(t);
}
/*
* QAccessibleTextInterface implementation below this point.
*/
void addSelection(int startOffset, int endOffset) override;
QString attributes(int offset, int* startOffset,
int* endOffset) const override;
// etc.
};
With Orca under Linux, everything seems to work as intended. I get calls to interface_cast() for a TextInterface, and after that, the various functions of QAccessibleTextInterface are called. With NVDA under Linux, I just get interface_cast() calls for ValueInterface, and none of the QAccessibleTextInterface functions are called. Which means MyWidget is completely inaccessible, unless I override QAccessibleWidget::text() and just return all text as a single string, which means no cursor navigation, no selection support... It basically becomes just a QLabel at this point, but with a ton of text and thus very hard to use.
What am I missing here?
Well, an NVDA developer helped me track down the issue. It's because the MinGW version of Qt has IAccessible2 disabled and uses MSAA (Microsoft Active Accessibility) instead, which doesn't support any of these interfaces. IA2 needs COM, and MinGW doesn't support that.
So I would have to switch from GCC/MinGW to MSVC to make this work on Windows. Too bad that's not actually an option in the foreseeable future :-/
2020 update:
This has been fixed since. Not sure when exactly, but the current mingw Qt builds now support this.
I have written an application in C++ using Qt 4.8 in Visual Studio 2010 and I try to make .exe with dlls. Everything seems to work just fine, but
when I run my program on another computer without any VS or Qt installed there, nothing gets displayed.
//class where I create database
DatabaseManager::DatabaseManager():
m_database(new QSqlDatabase(QSqlDatabase::addDatabase("QSQLITE")))
{
m_database->setDatabaseName("VirtualBank.db");
m_database->setHostName("localhost");
}
// Widget that has holds QTableView where that database gets displayed
CorporationWidget
{
//....
QTableView * m_wgt;
QSqlRelationalTableModel* m_model;
//....
}
void CorporationWidget::initializeModel()
{
setModel(new QSqlRelationalTableModel(this,*(getContext()->model->getDatabase())));
//....
}
Normal view: (on my computer)
Not normal view (on someone else's computer)
The dlls in folder:
This question has unfortunately been asked before but I'm going insane here.
In my Qt Application the user is able to dynamically change the language which works perfect for all my own translations. It does not work for my calls to QFileDialog. The respective code:
void myapp::change_language(std::string& lang_str){
// my own translations works
qApp->removeTranslator(&this->app_lang);
this->app_lang.load(QString::fromStdString(lang_str));
qApp->installTranslator(&this->app_lang);
// system translations, works not for qfiledialog
qApp->removeTranslator(&this->app_lang_qt);
bool test = this->app_lang_qt.load("qt_fr.qm"); // returns true
qApp->installTranslator(&this->app_lang_qt);
}
And
void myapp::changeEvent(QEvent* event){
if(event->type() == QEvent::LanguageChange){
this->ui.retranslateUi(this);
}
QMainWindow::changeEvent(event);
}
With
QTranslator app_lang;
QTranslator app_lang_qt;
The fixed string "qt_fr.qm" is just for testing purpose because french is easily detectable.
What I want is to change the language in static calls to QFileDialog and QMessageBox but the language is only changed in QMessageBox, not in QFileDialog. For both classes I'm only calling the static members to that can't be the issue. I also tried to install this translator in the main.cpp with the same results.
By default, QFileDialog will use the native file browser rather than a custom Qt-based dialog. The native file browser is will be using the OS language, rather than the Qt language, and will not have Qt translations applied to it. You can override this behaviour using the DontUseNativeDialog option for QFileDialog.
I am trying to load a Nib from a C++ constructor with Objective C++. I have searched and found enough examples to get some code together but it doesn't display the window. Or any windows for that matter.
Here is an example of the contructor:
JokeSystem::JokeSystem() : fileSystem("/Library/Application Support/Jokes/")
{
try
{
randSystem = new RandSelect<std::string>
(fileSystem.getAllFileContents("%\n"));
}
catch (std::ifstream::failure)
{
NSWindowController * errorWindowControl = [[NSWindowController alloc]
initWithWindowNibName:#"ErrorWindow"];
[errorWindowControl showWindow: nil];
}
}
The purpose of the contructor is to load the contents of a directory into a string. What I am try to do is display the error window when the files fail to open.
ErrorWindow.nib has a single window with an OK button and a NSTextView for the error, I set up a NSWindowController in the nib and connected it to the window.
My only link has been that most examples show this [errorWindowControl showWindow: self];
rather than showWindow: nil but because this is a C++ constructor I it doesn't have self and this doesn't work.
If it matters this contructor is called from the awakeFromNib method of the MainMenu.nib's primary NSObject.
Thanks
A bit of an odd way to approach Cocoa. I would encourage you to step back, learn Objective-C and then write your application with an Objective-C based Cocoa UI layer on top of whatever backing store or model layer you have.
In any case, there isn't anything particularly wrong with that code (save for the odd design).
The first thing to check is the return value of -initWithWindowNibName:. Is errorWindowControl actually non-nil? If it is nil, then the NIB failed to load.
How are you writing the Cocoa application itself? Standard app bundle using Xcode, I hope?
Also, you shouldn't be hardcoding the path to /Library/Application Support/. Actually, your application shouldn't use that directory as the only storage location; many users won't have write access to that directory and won't be able to install your app without administrator access.
I've made many different seperate parts of a GUI system for the Nintendo DS, like buttons and textboxes and select boxes, but I need a way of containing these classes in one Gui class, so that I can draw everything to the screen all at once, and check all the buttons at once to check if any are being pressed. My question is what is the best way organize all the classes (such as buttons and textboxes) into one GUI class?
Here's one way I thought of but it doesn't seem right:
Edit: I'm using C++.
class Gui {
public:
void update_all();
void draw_all() const;
int add_button(Button *button); // Returns button id
void remove_button(int button_id);
private:
Button *buttons[10];
int num_buttons;
}
This code has a few problems, but I just wanted to give you an idea of what I want.
This question is very similar to one I was going to post, only mine is for Sony PSP programming.
I've been toying with something for a while, I've consulted some books and VTMs, and so far this is a rough idea of a simple ui systems.
class uiElement()
{
...
virtual void Update() = 0;
virtual void Draw() = 0;
...
}
class uiButton() public : uiElement
{
...
virtual void Update();
virtual void Draw();
...
}
class uiTextbox() public : uiElement
{
...
virtual void Update();
virtual void Draw();
...
}
... // Other ui Elements
class uiWindow()
{
...
void Update();
void Draw();
void AddElement(uiElement *Element);
void RemoveElement(uiElement *Element);
std::list <uiElement*> Elements;
...
}
void uiWindow::Update()
{
...
for (list <uiElement*>::iterator it = Elements.begin(); it != Elements.end(); it++ )
it->Update();
...
}
void uiWindow::Draw()
{
...
for (list <uiElement*>::iterator it = Elements.begin(); it != Elements.end(); it++ )
it->Draw();
...
}
The princple is to create a window and attact ui Elements to it, and call the draw and update methods from the respective main functions.
I don't have anything working yet, as I have issues with drawing code. With different APIs on the PC and PSP, I'm looking at some wrapper code for OpenGL and psp gu.
Hope this helps.
thing2k
For anyone who's interested, here's my open source, BSD-licenced GUI toolkit for the DS:
http://www.sourceforge.net/projects/woopsi
thing2k's answer is pretty good, but I'd seriously recommend having code to contain child UI elements in the base uiElement class. This is the pattern I've followed in Woopsi.
If you don't support this in the base class, you'll run into major problems when you try to implement anything more complex than a textbox and a button. For example:
Tab bars can be modelled as multiple buttons grouped together into a single parent UI element that enforces mutual exclusiveness of selection;
Radio button groups (ditto);
Scroll bars can be represented as a slider/gutter element and up/down buttons;
Scrolling lists can be represented as a container and multiple option UI elements.
Also, it's worth remembering that the DS has a 66MHz CPU and 4MB of RAM, which is used both to store your program and execute it (DS ROMs are loaded into RAM before they are run). You should really be treating it as an embedded system, which means the STL is out. I removed the STL from Woopsi and managed to save 0.5MB. Not a lot by desktop standards, but that's 1/8th of the DS' total available memory consumed by STL junk.
I've detailed the entire process of writing the UI on my blog:
http://ant.simianzombie.com/blog
It includes descriptions of the two algorithms I came up with for redrawing the screen, which is the trickiest part of creating a GUI (one just splits rectangles up and remembers visible regions; the other uses BSP trees, which is much more efficient and easier to understand), tips for optimisation, etc.
One useful strategy to keep in mind might be the composite pattern. At a low level, it might allow you to treat all GUI objects (and collections of objects) more easily once built. But I have no idea what's involved in GUI framework design, so one place to find general inspiration is in the source code of an existing project. WxWidgets is a cross-platform GUI framework with source available. Good luck with your project!
I think looking at the way other GUI toolkits have done it would be an excellent place to start. For C++ examples, I hear lots of good things about Qt. I haven't used it personally though. And of course WxWidgets as Nick mentioned.
I've written a very simple GUI just like you propose. I have it running on Windows, Linux and Macintosh. It should port relatively easily to any system like the PSP or DS too.
It's open-source, LGPL and is here:
http://code.google.com/p/kgui/