125
I Use This!
Activity Not Available

News

Analyzed about 2 months ago. based on code collected 3 months ago.
Posted about 10 years ago
Cutelyst the Qt Web framework just got a new release! I was planning to do this one after Qt 5.5 was out due to the new qCInfo() logger and Q_GADGET introspection, but I'll save that for 0.10.0. This release brings some important API breaks so if ... [More] everything goes well I can do another CMlyst release. Some small performance improvements with QStringRef usage and pre-cached _DISPATCH actions Fixes when using uWSGI in threaded mode Speedup uWSGI threaded mode, still slower than pre-forked but quite close Fixes for the session handling as well as having static methods to make the code cleaner Fix uWSGI --lazy-apps mode Use PBKDF2 on Authentication plugin Requite CMake 3.0 and it's policy Add Request::mangleParams() and Request::uriWith() so that Request API now covers all of Catalyst's Documented some functions Cutelyst repository was moved to gitlab and then moved to github. The main website http://cutelyst.org is now powered by CMlyst and itself :) Download here. I also started another project, html-qt is a library to create a DOM representation of HTML following the WHATWG specifications, it's needed for CMlyst to be able to remove XSS of published posts, at the moment it has 90% of the tokenizer ready, and 5% of the parser/tree construction code, so if you have interest in the subject (could be potentially useful for mail clients such as KMail) give me a hand! [Less]
Posted about 10 years ago
Cutelyst the Qt Web framework just got a new release! I was planning to do this one after Qt 5.5 was out due to the new qCInfo() logger and Q_GADGET introspection, but I'll save that for 0.10.0. This release brings some important API breaks so if ... [More] everything goes well I can do another CMlyst release. Some small performance improvements with QStringRef usage and pre-cached _DISPATCH actions Fixes when using uWSGI in threaded mode Speedup uWSGI threaded mode, still slower than pre-forked but quite close Fixes for the session handling as well as having static methods to make the code cleaner Fix uWSGI --lazy-apps mode Use PBKDF2 on Authentication plugin Requite CMake 3.0 and it's policy Add Request::mangleParams() and Request::uriWith() so that Request API now covers all of Catalyst's Documented some functions Cutelyst repository was moved to gitlab and then moved to github. The main website http://cutelyst.org is now powered by CMlyst and itself :) Download here. I also started another project, html-qt is a library to create a DOM representation of HTML following the WHATWG specifications, it's needed for CMlyst to be able to remove XSS of published posts, at the moment it has 90% of the tokenizer ready, and 5% of the parser/tree construction code, so if you have interest in the subject (could be potentially useful for mail clients such as KMail) give me a hand! [Less]
Posted about 10 years ago
What is an Input Method and what do we need it for? To answer that question, let’s see what Wikipedia says: “An input method (or input method editor, commonly abbreviated IME) is an operating system component or program that allows any data, such as ... [More] keyboard strokes or mouse movements, to be received as input. In this way users can enter characters and symbols not found on their input devices.” So an input method allows you for example to input Chinese, Japanese, Korean or Indian characters into a text input field of an application, even though there is only a Latin keyboard attached to the computer. That is done by analyzing the text, which is typed in as Latin, and e.g. opening a popup menu with a pre-selection of Chinese characters, which are associated with that Latin input. The user can now select one of these Chinese characters, which will then replace the Latin input in the text field. Since input method support is nowadays an important requirement for UI toolkits, it doesn’t come as a surprise that our favorite one (aka Qt) provides it as well. But since Qt is cross-platform, it doesn’t support only a single input method, but various ones, depending on the target platform. In this blog post, we’ll have a closer look at how that is implemented, what classes are involved and where it can be extended or adapted. Input methods in Qt To get an overview of the input method handling in Qt, let’s have a closer look at the involved components first: QPA plugin: Since version 4.8, Qt contains an abstraction layer (Qt Platform Abstraction), to simplify the porting of the UI parts of Qt to new windowing systems. This layer consists of a set of abstract interface classes (QPlatform*), which are reimplemented for the target windowing system and are bundled as a plugin that can be loaded at runtime. The central interface is QPlatformIntegration, which is instantiated from the plugin by QGuiApplication on startup, and provides access to all the other QPA interfaces. QPlatformInputContext: The QPlatformInputContext is an abstract interface for the various input method systems that are available on the different windowing systems. For every supported system, there is a sub class of QPlatformInputContext, which implements the communication with the actual input method backend (e.g. QIBusPlatformInputContext for IBus). These subclasses are either available as standalone plugins, which can be loaded at runtime (Qt 5.4 ships two of them, ‘ibus’ and ‘compose’), or are compiled into the QPA plugin (e.g. QQnxInputContext for QNX and QWindowsInputContext for Windows). QPlatformInputContext is part of Qt’s private API, so as an application developer, you won’t access it directly, instead the global instance of the public class QInputMethod is used. This global instance is returned by QGuiApplication::inputMethod() and it simply forwards the calls to its methods to the global QPlatformInputContext instance. The latter is provided by the loaded QPA plugin (see QPlatformIntegration::inputContext()), which returns one of the above mentioned subclasses. QGuiApplication: The QGuiApplication inherits QCoreApplication and therefore contains the main event loop of the application, which is responsible for forwarding incoming events from the native windowing system to the appropriated objects in the application. While QCoreApplication only knows about the UI-independent events, the QGuiApplication has knowledge about UI-related states, like which widget has the active keyboard focus, what the current input method is etc. Text input widgets: The purpose of the text input widgets (e.g. QLineEdit or QTextEdit) is to visualize the keyboard input of the user in a textual representation. Since the key events, which come in from the native windowing system, cannot always be mapped to output characters one-to-one, the text input widgets need support from the input method system to do the conversion. Follow the stream While we now know the major players in the game and their roles, in the next step we’ll see how they interact with each other. For that, we follow a key stroke on the keyboard throughout the complete system until it shows up as character in a QLineEdit. The first thing we need in our application is an input widget, which is sensitive to keyboard input. That is easily done by instantiating a QLineEdit. If the user now wants to type in a Chinese character, the first of his actions would be to give this QLineEdit the input focus by either clicking on it with the mouse pointer or navigating to it via the tab chain. As soon as the QLineEdit receives the focus, a private slot in QGuiApplication is called (_q_updateFocusObject), which executes the following steps: check if the QPlatformIntegration provides a QPlatformInputContext object if so, check if the object with the input focus wants to use the input method system or handle key events itself informs the QPlatformInputContext about the new focus object The first check is easily done, since the QGuiApplication has loaded the QPA plugin itself, so it has access to the QPlatformIntegration instance and can simply call the QPlatformIntegration::inputContext() method to check if a valid QPlatformInputContext object is returned. The second check is a bit more advanced. To decouple the QGuiApplication from the QWidget interface (and e.g. support also focus handling for QQuickItem), it cannot just call a method on the focus object to query its properties, since that would require QGuiApplication to know their API. Instead QGuiApplication sends a synchronous event (a blocking invocation via QGuiApplication::sendEvent(QEvent*)) to the focus object. Then the focus object fills the event object with the requested information, and when the blocking call returns, the QGuiApplication extracts the information from the event. In short: synchronous event sending is used to decouple QGuiApplication from the public interface of the focus objects. So what does the event look like and what information can be queried? QInputMethodQueryEvent is the actual event that is used to query the information, and it allows QGuiApplication to query information from the focus object like: does it accept input method input (Qt::ImEnabled) the text around the current input area (Qt::ImSurroundingText) preferred input language (Qt::ImPreferredLanguage) and many, many more (see Qt::InputMethodQuery). In our case QGuiApplication sends a QInputMethodQueryEvent to QLineEdit and asks for the Qt::ImEnabled flag. QLineEdit responds to that event in the reimplemented QWidget::inputMethodQuery() method, by checking if the Qt::WA_InputMethodEnabled widget attribute is set. This attribute needs to be set by any widget that wants to use the input method system and is set by default on the text input classes (QLineEdit, QTextEdit etc.) in Qt. The last of the steps executed by _q_updateFocusObject() is to inform the QPlatformInputContext object about the new focus object, so that it can query further information from the focus object if needed later on during the input process. That is simply done by invoking QPlatformInputContext::setFocusObject(QObject *object). Now that the QLineEdit has the keyboard focus, the user might press a key on the keyboard, which will trigger an input event in the operating system, which will be forwarded to the windowing system and from there call some function in the currently loaded QPA plugin. At that point the QPA plugin would transform the native key event into a QKeyEvent and inject it into the applications event queue by calling QWindowSystemInterface::handleKeyEvent() or QWindowSystemInterface::handleExtendedKeyEvent(). If however an input method system is active, (in that case (QPlatformIntegration::inputContext() returns a valid QPlatformInputContext object), it will send the raw input data to the QPlatformInputContext object instead. How the raw input data are sent to the QPlatformInputContext in that case is not defined by any API, so every QPA implementation is free to choose how to do it. The XCB QPA plugin for example expects the QPlatformInputContext to provide a public slot ‘x11FilterEvent’, which it invokes with QMetaObject::invokeMethod() and passes the xcb_keysym* data as parameters. That dynamic invocation allows us to use different QPlatformInputContext implementations on XCB systems, without having the XCB QPA plugin know the exact class interface. The QNX QPA plugin on the other hand has the QQnxInputContext compiled in, so it has a pointer to that instance and simply calls a method to forward the raw input data to it. The QPlatformInputContext subclass has got the raw input data now and can forward them to the actual platform specific input method backend (e.g. send to IBus server via DBus). At that point the input method backend might require additional information to process the current raw input data. Example information could be: the text around the current input area, to interpret the new input data in a context the location of the cursor, to open character selection popup menu next to it To query this information, the QPlatformInputContext sends a synchronous QInputMethodQueryEvent to the current focus object again, exactly as QGuiApplication has done it before. Once it has retrieved this information from the focus object, and forwarded it to the input method backend, the backend will compose a final character (or sequence of characters) that should be set as the new text on the QLineEdit. The composing is either done programatically (by following some writing system specific rules), or the input method system opens a popup menu with a pre-selection of possible characters from which the user selects an appropriated character. So how does the composed text get back to the QLineEdit? For that, another synchronous event invocation is done. The QPlatformInputContext creates an instance of QInputMethodEvent and calls setCommitString() on it, with the newly composed text as parameter. Afterwards it sends the event to the focus object. On the focus object, the QLineEdit in our case, the reimplemented method QWidget::inputMethodEvent(QInputMethodEvent*) is invoked. That method will update the current text of the QLineEdit with the composed text, reposition the text cursor and possibly update the current selection. At that point, the key press event has reached its destination and the user is going to press the next key on the keyboard. In addition to the commit string, the QPlatformInputContext could also create a QInputMethodEvent with a preedit string and send it to the focus object before composing has started or while composing is in progress. That preedit string is then shown inside the QLineEdit as intermediate result. The visual appearance of that text can be influenced by setting certain attributes on the QInputMethodEvent. In the next blog post we will learn how to implement an out-of-process virtual keyboard, that uses Qt’s input method framework to communicate with Qt-based applications. Stay tuned! The post Qt Input Method – In Depth appeared first on KDAB. [Less]
Posted about 10 years ago
Last year I gave a talk for the London Haskell User Group on building a Sticky Notes application using Haskell, Qt, and the HsQML binding between them. The video has been out for a while now and made the rounds elsewhere, but I've thus far neglected ... [More] to post it on my own blog! Slides are here. See below for an update on the example program and an answer to the most commonly asked question after the fact. Fast and Slow? An update! For the sakes of simplicity, the original version of the sticky notes program shown in the talk uses an SQLite database to serve the view directly with no in-memory model or caching. This is at least the cause of some sluggishness and at worst pathological performance depending on your machine. As alluded to in the talk, there is a better albeit more complicated way. This involves moving the slow database accesses onto a separate thread and keeping a fast in-memory model to support the user interface. Changes made by user are now queued up and then flushed to disk asynchronously. I've now released an updated version (0.3.3.0) of the hsqml-demo-notes package which includes a new faster version of the program illustrating exactly this technique. This hsqml-notes executable is now built using the new code and, for reference, the original code is built into the hsqml-notes-slow executable. The fast variant uses three MVars to communicate between the UI and database threads. An MVar is kind of synchronisation primitive offered by Haskell akin to a box which may either contain a data value or be empty. Operations on MVars take out or put in values to the box and will block if the MVar is not in the appropriate state to accept or produce a value. Hence, a variety of different constructs such as locks and semaphores can built out of MVars. The first MVar in the new notes code, modelVar, contains a Map from note IDs to the data associated with each note. This is the in-memory model. It includes all the fields held in the database table plus an additional field which indicates whether there are any pending changes which need flushing to the database (whether the record is "dirty"). The MVar semantics here act as a lock to prevent more than one thread trying to manipulate the model at the same time. A second MVar, cmdVar, is used as a shallow channel for the UI thread to signal the database thread when there is work to do. The database thread normally waits blocked on this MVar until a new command value is placed in it, at which point it takes out and acts upon it. The first command given to the database thread when the program starts is to populate the model with the data stored on disk. Thereafter, whenever a user makes a change to the model, the dirty bit is set on the altered record and a command issued to the database thread to write those dirty records to the database. Finally, the third possible type of command causes the database thread to close the SQLite file and cleanly exit. In that case, the third MVar, finVar, is used as a semaphore to signal back to the UI thread once it has shut down cleanly. This is necessary because the Haskell runtime will normally exit once the main thread has finished, and the MVar provides something for it block on so that the database thread has time to finish cleaning up first. What is the FactoryPool actually for? QML objects require a relatively explicit degree of handling by Haskell standards because the idea that data values can have distinct identities to one another even if they are otherwise equal is somewhat at odds with Haskell's embrace of referential transparency. This sense of identity is important to the semantics of QML and can't be swept under the rug too easily. Crucially, using signals to pass events from Haskell to QML requires that both the Haskell and QML code are holding on to exactly the same object. One way to accomplish this is to carefully keep track of the QML objects you create in your own code. The factory-pool is an attempt to provide a convenience layer atop object creation which saves the programmer from having to do this. It is essentially an interning table which enforces the invariant that there is no more than one QML object for each distinct value (according to the Ord type-class) of the Haskell type used to back it. If you query the pool twice with two equal values then it will give you the same object back both times. Importantly, it uses weak references so that objects which are no longer in use are cleared from the intern table and it doesn't grow in size indefinitely. One of the difficulties people have had with understanding the factory-pool from the notes example is that it's not generally necessary to make it work. Aside from the initial loading of the database, all the activity is driven from the front-end and so displaying a single view isn't strictly reliant on the signals firing correctly. If you replace the code to retrieve an object from the pool with a plain object instantiation, the default QML front-end for the demo would still work the same, albeit more wastefully. To see the pool doing something useful, try the "notes-dual" front-end (by specifying it on the command line), which I've come to think of as the most interesting of the demos. It displays two front-ends simultaneously backed by the same data model. Changes in one are immediately reflected in the other. This works because when each front-end retrieves the list of notes they both obtains the same ObjRef from the pool for each Note as each other. Hence, when a change is made in one front-end, and a change signal is fired, both the front-ends receive it and remain in sync. Without the pool, the onus would be on the application code to keep track of the objects in some other fashion. For example, if each read of the notes property created a new set of objects every time it was accessed then many more objects would need to have signals fired on them in order to ensure that every piece of active QML had received notice of the event. Each front-end would still be backed by the same data, methods and properties would still have access to the same set of Note values, but their objects would be distinct from the perspective of signalling and, unless special care was taken, the front-ends wouldn't update correctly. [Less]
Posted about 10 years ago
 
Posted about 10 years ago
It was a great weekend in Oslo, 5-7th June! Over a hundred Qt contributors gathered right next door to The Qt Company offices to talk about the current state and future of Qt. The Friday pre-event drew a good crowd, who met up at The Qt Company ... [More] offices. As the weather was nice, we went out for a picnic in the nearby park. This set the feeling of Qt Contributors’ Summit well, as it is a gathering of a community The program for the weekend contains the session notes. The topics ranged from the upcoming QtCreator UI style changes to long term support in Qt. Every session drew an active crowd and there were many discussions. Between every session there was time to talk in the hallways, a very important part of a good Qt Contributors’ Summit. For those of you who were taking notes in sessions, if you haven’t yet, please go and update the notes for the session on the wiki. Also for at least the more technical sessions, please post the notes to the Development mailing list, so as to make sure people who need to see the notes really do see them. Memorable things from this years summit include the strong attendance from Japan, three community members present. We also had  three of the current four Qt Champions present at the same time! The Saturday evening event was held together with The Qt Company and local old trolls. The venue had a nice sunny balcony, and people enjoyed themselves after a long day of sessions. I want to thank everyone who made this Qt Contributors’ Summit a great event. Our sponsors; The Qt Company, Intel, Boundary Devices, ICS, Froglogic,KDAB, e-Gits and Pelagicore. And Aliz and Anca from The Qt Company offices were an invaluable help in the event practicalities. But most of all, thank you to everyone who attended. Hope to see you all in Berlin at the Qt World Summit! The post Back home after Qt Contributors’ Summit 2015 appeared first on Qt Blog. [Less]
Posted about 10 years ago
... a.k.a. "all auto tests in the master branch are always passing".   Imagine this typical scenario: You are working on a project with Git, and the classes are tested via auto tests. Unfortunately, many of the tests are often broken (typically by ... [More] your co-workers, not by yourself, right?) and will be fixed "tomorrow" (which can mean anything from tomorrow until never). A better way is this: You do not push to the master branch (or stable etc.) directly, but to a special branch; then that branch [Less]
Posted about 10 years ago
In the next installment of this blog series on the lesser-known Qt commands, we'll look at the QML-related tools that come with Qt 5. qml This program is the so-called QML tooling, which allows running QML files directly like a script, much like ... [More] UNIX shell scripts or Python programs. I've covered this specific topic before and and refer you to that previous blog post 1 for more details. [Less]
Posted about 10 years ago
The new V-Play update 2.4.2 adds two more sample games: the falldown game Chicken Outbreak 2 and the action game Crazy Carousel. Both games are included with full source code in the free V-Play SDK, and help you to learn V-Play faster. You can also ... [More] use the games as a foundation for your own game. See below how to run the new demo games. Simpler License Generation for V-Play Qt Plugins To make a game that is in top of the charts, you need to measure & constantly improve it. For this challenge, you can use Flurry or Google Analytics and integrate them with just 10 lines of code into your game. With a V-Play License, you get access to these and many more plugins that help you to analyze, monetize & improve your game. Before V-Play 2.4.2, you needed to generate a separate license key for each plugin. Since this new update, you can simply select the plugins you like and are all set for integrating the plugin to your game: As a V-Play Customer, you can now use this simplified license key generation for all plugins here. New Open-Source Falldown Game: Chicken Outbreak 2 Chicken Outbreak 2 is the second part of the original V-Play falldown game with your goal to escape from a Western-style henhouse. It uses many features you can also use in your game like: Physics: Used for movement and collision detection. Multimedia: Play a background music and sounds. VPlayGameNetwork: Achievements, Leaderboards for comparing highscores across platforms. Soomla In-app Purchase Plugin: Purchase power-ups and more. Chartboost Plugin: Get revenue from ads. Facebook Plugin: Sync the game state across multiple devices & platforms, together with V-Play Game Network. Flurry Plugin: Analyze user behavior to improve the game. To play & test this game, see Play the Games below. New Action Game & Game Tutorial: Crazy Carousel Crazy Carousel is a mini-game with the goal to collect as many coins as possible while avoiding to get hit by paper planes. You can collect the coins or avoid the paper planes by jumping from one carousel ride to another. To jump, just swipe to the left or the right. We also created a complete step-by-step tutorial for you on How to Create the Crazy Carousel Game with V-Play! This new demo game is a showcase project that combines several important aspects of the V-Play engine. It uses these features: Support multiple screen sizes and resolutions Provide images in different resolutions for multiple devices for best performance Handle multiple game scenes Move objects with animation components Use background music and sound effects Dynamic object creation based on timers Use swipes to control the player character Collision detection with the physics components In addition, the game shows how you can get a 3-dimensional feeling into your 2D-game! We accomplished that by using images that simulate a 3D room and a special animation of the paper planes and coins, that also scales them up when coming closer. Play the Games To play & test the games (you might need some of the source code implementation for your own game!), follow these steps: 1.) Update V-Play After you installed V-Play, open the V-Play SDK Maintenance Tool in your V-Play SDK directory. Choose “Updates components” and finish the update process to get the latest version 2.4.2 as described in the update guide. If you did not install V-Play yet, you can do so now with the latest installer from here. 2.) Start the Sample Launcher The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo games that come with the V-Play SDK, from a single desktop application. After installing the V-Play SDK, you can start it from /Examples/V-Play/sampleLauncher. Now just choose one of the two new demos, and you can explore & copy the source code right from within the Sample Launcher.   P.S.: For a detailed changelog of the update, see here.   The post Update 2.4.2: New Action & Falldown Game Samples, License Update appeared first on V-Play Game Engine. [Less]
Posted about 10 years ago
We want you, our faithful blog reader, to be the first to get the goods on what’s happening at Qt World Summit. We are very excited to announce Qt’s most anticipated business and technology event will be returning to Berlin October 5-7. Registration ... [More] is officially open! The global event for all things Qt This will be the 12th annual Qt event, so you can expect the same greatness you’ve experienced in the past, but now with a more unified and integrated approach covering business strategy and the code behind it. Your ticket will get you 3 days of everything Qt, 75+ sessions, and 8 training options. We’re still working on all the conference details and the full content schedule, but whether you are a technology director, business decision maker, tech strategist, product manager, engineer or developer there is something here for you. You’ll experience all this with hundreds of your closest and smartest friends in the Qt community. In addition to the exceptional learning opportunities, we’re planning some networking experiences that will knock your socks off. World-Class Training from Diamond Sponsor, KDAB Two days is just not enough to pack in all the great content we have in store for you! Why not join us a day early for one of 8 pre-conference training options from KDAB, spanning all topics from Qt fundamentals to advanced areas? QtWS15 Welcomes Top Sponsors We are very happy to have ICS as our Platinum sponsor. A huge thanks also to e-GITS and Froglogic as Gold sponsors, basysKom as Silver sponsor, and KDE Community as Partner. Together we will make Qt World Summit 2015 an event you won’t forget. Thinking about becoming a Qt World Summit sponsor? Please contact us. Registration Now Open: Early Bird, Student Discount, Bring the Team Offer Sign up now to get early bird pricing. It’s only available until July 13 and it’s the lowest possible price this year! Are you currently enrolled in a college or university? Get your unique student discount code here. There really is too much good stuff for one person to see. Take advantage of the Bring the Team Offer! Tip: You probably already know that your investment of time and money in QtWS will pay for itself and then some. Need help convincing your manager? Download the justification e-mail, tailor it to fit your situation, then send it on for approval. As you register for Qt World Summit 2015, don’t forget to share that you’re attending. The official event hashtag is #QtWS15, and you can follow the buzz on Facebook, Twitter, and LinkedIn. If conference registration opens and no one tweets about it, is it even a conference at all…? Look forward to connecting, and happy registering! The post Play ball! Qt World Summit 2015 Registration Now Open! appeared first on Qt Blog. [Less]