Pillow is a PIL fork created to add new features. setuptools support was also added. A more frequent release cycle was also promised. With Pillow you can have PIL as a package dependency in setuptools and virtualenv. That means less clutter and robustness for the development. :-)
Pillow allows you to continue to use import PIL , so there is no need to change your current PIL related code.
0 migration overhead.
Archlinux already dropped support for PIL in favor of Pillow.
TL;DR PIL > Pillow
# python 2.7
import math
reload(math) # or import math again to reload the module
del(math) # unload module
# python 3.x
import math
# the reload function was eliminated on python 3
import math # or use exec("import math")
del(math) # remove module
Today I was trying to create a simple parser to count syllables in latin words with Prolog. I usually use DCGs in Prolog for parsing. Their semantic is very similar to BNF . I love DCGs, but sometimes the verbosity in some cases annoys me. Take the following example:
consonant -->
"b"; "c"; "d"; "f"; "g"; "h"; "l"; "j"; "k"; "m";
"n"; "p"; "q"; "r"; "s"; "t"; "v"; "x"; "z".
consonants -->
[].
consonants -->
consonant, consonants.
vowel -->
"a"; "e"; "i"; "o"; "u".
vowels -->
vowel.
vowels -->
vowel, vowels.
syllable -->
vowels.
syllable -->
consonants, vowels.
syllables(0) -->
[].
syllables(N) -->
syllable, syllables(N_1),
{ N is N_1 + 1 }.
The vowels and consonant rules were created merely as helpers for the syllable predicate. That could be reduced if I had regex operators like +, * or ?. Although there are modules for using regex in Prolog ( swi-regex ), it is not suitable when using within in DCGs. So I wrote these regex like operators, with meta DCG predicates, for DCG (like EBNF operators):
% op statements let me use them without parenthesis
:- op(100, xf, *).
:- op(100, xf, +).
:- op(100, xf, ?).
*(_) -->
[].
*(EXPR) -->
EXPR, *(EXPR).
+(EXPR) -->
EXPR.
+(EXPR) -->
EXPR, +(EXPR).
?(EXPR) -->
[].
?(EXPR) -->
EXPR.
They allow me to modify the times a given rule will be matched. So, I can replace this:
consonants -->
[].
consonants -->
consonant, consonants.
vowels -->
vowel.
vowels -->
vowel, vowels.
syllable -->
vowels.
syllable -->
consonants, vowels.
with a simpler version without intermediate rules (using the operators definition through a library):
syllable -->
*consonant, +vowel.
Are you too lazy to learn your debugger? When debugging, I usually want to know if some code section is reached.
I can do this:
void foobar() {
printf("foobar()\n");
// ... do foobar
}
But I should use
cout instead printf in C++ .
printf is faster, but in this case it should be irrelevant.
So I have:
void foobar() {
std::cout << "foobar()" << std::endl;
// ... do foobar
}
I could also use GCC's function name macro __PRETTY_FUNCTION__ and __LINE__ macro to identify the reached code section easier.
void foobar() {
std::cout << __PRETTY_FUNCTION__ << " at line " << __LINE__ << std::endl;
// ... do foobar
}
Add that on a macro to reuse it:
#if DEBUG
#include
#define REACH std::cout << __PRETTY_FUNCTION__ << " at line " << __LINE__ << std::endl;
#endif
void foobar() {
REACH
// ... do foobar
}
And happy debugging!
Not.
bool m_visible;
Display* m_display;
Window m_window;
void setVisible(bool visible)
{
if (visible == m_visible)
return;
if (visible)
XMapWindow(m_display, m_window);
else
XUnmapWindow(m_display, m_window);
m_visible = visible;
}
For the last few months my team (OpenBossa) at INDT (Instituto Nokia de Tecnologia) have been working on WebKitNix (Nix for short). WebKitNix is a new WebKit2 port, fully based on POSIX and OpenGL. We also use CMake build system (like GTK and Efl), GLib, libsoup (networking) and Cairo (2D graphics) as dependencies. It also uses Coordinated Graphics and Tiled Backing Store from WebKit2. Many of its building blocks are shared with others ports already on trunk.
The Nix port offers a C API for rendering a WebView within a OpenGL context, based on WebKit2 API. You can use Nix to create applications such as a web browser or a web runtime. WebKit2 run the context for each web page in a different process. This process isolation keeps the UI responsive, with smooth animations and scrolling, because it does not get blocked by Javascript execution.
We want to ease the work of Consumer Electronics developers who wants to have a web runtime in their platform, without the need to create another WebKit port. That is why Nix has less dependencies than Efl, GTK or Qt, which should also be ported to the target platform.
Nix API also enables the application to interact with the Javascript context. So it is possible to add new APIs, to handle application specific features.
The OpenBossa team used to maintain the Qt WebKit port for years, helping Nokia/Trolltech. But then, in the last years, from the experience gathered with the Snowshoe browser, handling with dependencies (such as QtNetwork) that were much bigger than we really needed. We tried to replace some dependencies of QtWebKit and later Efl to see how minimal WebKit could be. So we took some steps:
When you compile Nix source code you can run the MiniBrowser to test it:
$ $WEBKITOUTPUTDIR/Release/bin/MiniBrowser http://maps.nokia.com
The Nix-Demos repository offers some example code, including a Glut based browser and minimal Python bindings for Nix: https://github.com/WebKitNix/nix-demos.
On Nix-Demos we also have a Nix view, using only a DispmanX and OpenGL ES 2 working on the Raspberry Pi. To compile this demo, you will need our RaspberryPi SDK .
There is even a browser with its UI written in HTML: Drowser
Feel free to contact us on #webkitnix at freenode.
Our plan is to upstream Nix in WebKit trunk by June/2013. Then, keep the maintainence and focus on the web platform, including some new HTML5 features, such as WebRTC.
It was a great event! Thanks to everyone who made it happen.
OpenGL is a primarily an C API, for drawing graphics. Implementations and bindings exists for several languages such as Java, Python, Ruby and Objective C. OpenGL became the standard drawing API supported by most modern device with graphics, independent from vendor, operational system, or if it is desktop or embedded. Of course the platform matters, but we can split the platform dependent code from pure OpenGL.
OpenGL became a standard mainly due to its rendering pipeline, which is trivially parallelized. This allowed the creation of specialized hardware, the well known graphics cards. These cards became very small and started to be practical shipping embedded devices with them. Now high performance graphics in these devices are a reality.
On traditional desktop platforms, the usual layout of graphics card stand as pictured below. In this scenario, moving data to and from the card can mean a huge cost. On others platforms, such as the mobile, its common that GPUs uses the same memory as the CPU. However, the programmer still needs to handle this memory efficiently.
For this new range of devices, the Khronos (group responsible for standardizing OpenGL API) released an OpengGL specification focused on embedded systems, the OpenGL ES.
In this post I would like to explain some key concepts about the OpenGL API:
Enough talking, show me the code! I wrote the following code using GLUT and OpenGL 1. GLUT is a simple toolkit to create simple OpenGL applications. It basically opens an window with a GL context, and handles primitive mouse and keyboard events.
#include <GL/gl.h>
#include <GL/glut.h>
void display()
{
glClear(GL_COLOR_BUFFER_BIT); // Clean up the canvas
glBegin(GL_TRIANGLES);
glVertex2f(-1.0f, -1.0f);
glVertex2f( 0.0f, 1.0f);
glVertex2f( 1.0f, -1.0f);
glEnd();
glFlush(); // Forces previous GL commands to be send to the GPU
}
int main(int argc, char **argv)
{
glutInit(&argc, argv);
glutInitWindowSize(480, 480);
glutCreateWindow("Hello World");
glutDisplayFunc(display);
glutMainLoop();
return 0;
}
In OpenGL 1 and 2, the easiest way for you to draw a triangle, is using some form of glVertex*.
These call must be enclosed between glBegin and glEnd.
OpengGL uses a coordinate system where the origin is the center of the viewport, the X axis has left to right orientation and Y axis is bottom to top, as pictured below. By default everything between (-1, -1) and (1, 1) is what youll be shown in the viewport. Check this tutorial for understanding OpengGL coordinate system and camera deeper.
You also need to assert what kind of primitive you are passing to OpenGL. It accepts the primitives illustrated below with their correspondent constants. OpenGL ES does not support polygon or quads, you will need to assemble them yourself.
Interleaved with the vertex position, you can add other information such as colors, texture coordinates, normal direction. You can define other vertex attributes for richer shaders. Shader is a piece of code that defines how your primitives will be rendered. With them is possible to make a lot of effects such as normal mapping, adding shadows, particles and many more. When we choose a shading model we are using OpengGL default shaders. Standard OpengGL defines a large set of inputs and outputs a shader must have. OpenGL ES 2 and above does not defines what you must enter as input for the shaders. Is up to the programmer what will be the inputs vertex shader will have. The contract assumes that the vertex shader will return at least a position (search for gl_Position) and the fragment shader a color (gl_FragColor). Do not worry. This will be further detailed in a following post.
Drawing with glVertex* was deprecated from OpenGL 3 and beyond.
In OpenGL ES we do not have them either.
This drawing method overheads of one function call for each information entered in the pipeline.
The OpengGL comittee also wanted to disencourage the usage of this kind of input mode.
The interfere of this overhead is small for small objects, but is not true for large ones.
Another reason, for removing them (specially on ES version), was the make OpenGL implementation lighter, by reducing the number of internal states.
Prefere to draw using vertex arrays.
Vertex arrays are arrays that each element contains all the vertex information.
The command to draw them is glDrawArrays .
Indexes can be specified to reuse the vertex definition by using glDrawElements.
A good reference for this subject is this one .
As this is the standard way when using OpenGL ES 2, I will give an example.
To draw a square you must first define the schema of each vertex. Here, each vertex has a position (3 floats) and a color (3 floats for R, G and B color channels). In C I like to define a struct to improve readability:
struct vertex_t {
GLfloat position[3];
GLfloat color[3];
};
void display()
{
struct vertex_t vertex_data[] = {
{{-1.0f, -1.0f, 0.0f}, {1.0f, 0.0f, 0.0f}}, // red bottom left
{{-1.0f, 1.0f, 0.0f}, {0.0f, 1.0f, 0.0f}}, // green top left
{{ 1.0f, -1.0f, 0.0f}, {0.0f, 0.0f, 1.0f}}, // blue bottom right
{{ 1.0f, 1.0f, 0.0f}, {1.0f, 1.0f, 1.0f}}, // white top right
};
// ...
}
It is possible to have different arrays for color and position, but for speeding up the shader execution is recommended to keep information about the same vertex contiguous to use memory locality.
glVertexAttribPointer(
position_attribute_location, // attribute description (depends on the shader)
3, // size of the information (3 coordinates in this case)
GL_FLOAT, // type of the information
GL_FALSE, // if the value will be normalized (for vectors)
sizeof(struct vertex_t), // stride of the memory vector
&vertex_data[0].position // initial address
);
// asserting that position will be used by the shader
glEnableVertexAttribArray(position_attribute_location);
glVertexAttribPointer(
color_attribute_location,
3,
GL_FLOAT,
GL_FALSE,
sizeof(struct vertex_t),
&vertex_data[0].color
);
// asserting that color will be used by the shader
glEnableVertexAttribArray(color_attribute_location);
// Draw a triangle strip vertex from the current attribute pointers
// starting on index 0 and using 4 elements
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
This gives us the following result:
Notice that the colors for each vertex stands as the ones we gave, but all the region in between has the color calculated as the interpolation of the vertex colors. The rasterizer is the responsible for doing this.
You could also use indexes to access the vertex. For bigger elements it may be a better solution, specially for 3D objects, because you can share vertex that appears in multiple polygons of an object. Using index would speed up the memory transfer and usage for these objects.
GLubyte indices[] = {
0, 1, 2, // first triangle
1, 2, 3 // second triangle
};
glDrawElements(
GL_TRIANGLES, // not a strip in this case
6, // number of indexes
GL_UNSIGNED_BYTE, // type of the indexes
indices // a pointer to indexes themselves
);
The previous code does it for a trivial shader set (called a program).
I will not explain how to use it here because is out of the scope for this lesson.
On regular OpenGL versions you could use glVertexPointer and glColorPointer.
I will left it as an exercise for you.
Buffers are objects that stores vertex information in GPU memory. It is a must for improving the performance when drawing large objects. In heavy application such as games or CADs, is good to remove the overhead of from sending vertex data from regular memory to graphics card memory by pre loading the vertex data in a buffer. The code below show how can you upload the vertex data to a buffer.
GLuint bufferId;
// here you get handlers for GPU buffers, in this case, only one
glGenBuffers(1, &bufferId);
// asserts that you are using the buffer represented by bufferId
// as the current ARRAY_BUFFER
glBindBuffer(GL_ARRAY_BUFFER, bufferId);
glBufferData(
GL_ARRAY_BUFFER, // the data is uploaded to current array buffer
sizeof(vertex_data), // number of bytes of the total array
vertex_data, // the pointer to the data
GL_STATIC_DRAW, // hint of how the buffer will be used, in this case, data will not change
)
To draw the buffer content, you must use glVertexAttribPointer passing the buffer offset
instead of the vertex_data address.
OpenGL will notice that a buffer is bound and will use it.
glBindBuffer(GL_ARRAY_BUFFER, bufferId); // Bind whenever you will use it
glVertexAttribPointer(
position_attribute_location, // attribute description (depends on the shader)
3, // size of the information (3 coordinates in this case)
GL_FLOAT, // type of the information
GL_FALSE, // if the value will be normalized (for vectors)
sizeof(struct vertex_t), // stride of the vertex buffer data
0 // offset at buffer
);
// asserting that position will be used by the shader
glEnableVertexAttribArray(position_attribute_location);
glVertexAttribPointer(
color_attribute_location,
3,
GL_FLOAT,
GL_FALSE,
sizeof(struct vertex_t),
3 // offset at buffer
);
// asserting that color will be used by the shader
glEnableVertexAttribArray(color_attribute_location);
// Draw a triangle strip vertex from the current attribute pointers
// starting on index 0 and using 4 elements
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
// Unbinds the buffer
glBindBuffer(GL_ARRAY_BUFFER, 0);
OpenGL ES 2 does not have the model-view matrix, responsible for setting the camera view, nor the matrix stack. All you have is the X axis [-1.0, -1.0] to Y axis [1.0, 1.0] region which will be mapped to the viewport. If you need those features (you will for most 3d applications) you will have to handle them inside your application code. You will have to do it yourself by exporting a model-view in the vertex shader as an uniform variable. For a theorical background on it, check my previous lesson . A great tutorial on how to play with the camera, transformations and model coordinates is this . It explains a bit how it works under the hood for regular OpenGL. Its worthy to take a look.
While hacking some examples I have come to some weird behaviour in OpenGL ES 2.0 for the Raspberry Pi. It might be bugs or mine misinterpretation.
glUniformMatrix4fv translate parameter must be false. It simply does not work otherwise. glDrawElements did not worked with unsigned int. This slides are from a lecture about OpenGL I'm giving at INDT. The first lesson was to refresh some important math concepts that will be important to understand how OpenGL works under the hood.
The slides are simply pictures of the board. Yes, they are in portuguese.
Feel free to make a question in the comments.
Last month, the 13rd FISL (Free Software International Forum) happened in Porto Alegre , in the very south of Brazil. It was a great opportunity to see what's going on in the free software community besides Qt and KDE in Brazil.
It was a great to see again some friends from KDE Brazil and met some new ones. The Konqui
I also gave some talks and workshop about Qt, KDE and game development.
This workshop was idealized and given by Sebas , and I was there for helping him, specially with the language barrier. In the workshop, QML was introduced together with KDE libs and what they can add to the applications.
Was good to show the current state of the Plasmate and how easily is creating and deploying a new Plasmoid. It was interesting to see how people were amazed about how easy is to start hacking and deploying a project.
This is the slide we used during the workshop:
In this talk I gave an overview about what Qt is and which tool are available for creating games with it.
On the third day I gave a 3 hours hands-on workshop about game development using only QtQuick. During the workshop, I've presented basic QtQuick and some basic game concepts such as the game loop, collisions and physics. I also tried to apply to explain how these concepts match with the QML development.
I created a simple click game Monera as an example to the attendees. The code was written step by step and used itself as example and introduction to QtQuick. It was possible for everyone to write the code on their own computers and test.
In the end also gave them a overview about how to install the QML-Box2D and how to use it's API.
The code used as case is available on GitHub: https://github.com/dakerfp/Monera-Game
Unfortunately I didn't used git to keep the history of steps, modularization and refactoring I did during the workshop. I think that would be a plus to understand the code and how we came to it.
This was my first time on FISL and it was great! And I expect that won't be my last.
This post is an update about the research project from my team, described a few weeks ago.
From the time we published the last post about QML Styling until now we have worked on this set of issues/features:
Last week, we have read a few blog posts, and talked with a few Qt & KDE application developers about what should be the priorities for creating desktop and mobile applications. I have presented our proposed solution for using native look and feel for QML widgets, how to create custom styles from scratch, using the CustomStyles helper, and how to apply them with the ApplicationStyle API.
Based on the feedback and the blog posts, my team sat down and came with the following set of statements which summarize our vision for what sould be our focus of our current research:
We decided to choose the ComboBox component to work on because it is one of the most complex (if it isn't the most). Because of the complexity, we hoped that during its development we could be enlightened of knowing if we are in a correct path, what still misses, and what should be the next steps.
As we did in the Slider approach, which was divided in 3 different subcomponents:
While creating the ComboBox, we decided to divide it in 4 other subcomponents:
We basically mimicked how QStyle splits the QComboBox painting into subcontrols. The drop list was also delegated a sub style as QComboBox does with it's internal QListView. We haven't worked on the drop list style since it would require a native style such as Plasma's ListItemView, which also would rely on a ScrollBar.
Creating the combo box component showed us that positioning and size hints can be more tricky than it looks like.
The ComboBox got stuck in a few parts and unfortunately it's not complete right now. However we took the questions and answers from its development. :-/
This topic of discussion came out when we were thinking about a theoretical style in which
the ComboBox would be in the left.
One of the issues we had in mind while developing the editable ComboBox
was how to set a MouseArea that can know when set the focus to the text edit or to open the drop list.
This would be possible to be done with current QStyle, since on it's approach the QWidget reads the subcomponent's size hints by the subControlRect method from QStyle.
We would like to have this positioning information on the style as well. The approach can be similar to what happens with the size, which you can read it from the widget reference.
The following piece of code is a simple example of how size hints can be taken:
// ComboBox.qml
Item {
property alias arrowStyle: arrowControl.sourceComponent
Loader {
id: arrowControl
width: arrowControl.implicitWidth
height: arrowControl.implicitHeight
}
MouseArea {
anchors.fill: arrowControl
onClicked: {
// do some action
// ...
}
}
}
ArrowStyle defines the implicit size, which works as a size hint, and the position where they are.
These properties together can work analogue to subControlRect, as they hold the same info.
The component may ignore such hints and override the properties values, such as Slider's Handle style position.
// MyComboBoxArrowStyle.qml
Image {
implicitWidth: 50
implicitHeight: comboBox.height
x: comboBox.width - width // Arrow could also appear on the left by setting x = 0
source: "arrow.png"
}
One may ask "Can't I have a round button with a circular hit area?" That's more complex than just setting hints for the geometry of sub control styles. As we defined in our view we're trying to be at least as powerful as QStyle. We consider that, by now, we should be strict at least about the interaction styling of the components themselves. From my point behaviour difference should be defined as the component API.
Another discussed topic was about the fragmentation of the style property of the components. For instance, take the following Slider style code:
// Slider style now
Slider {
grooveStyle: CustomGrooveStyle { ... }
handleStyle: CustomHandleStyle { ... }
}
The Slider style property is fragmented as more than one property. We thought that these properties could be centralized with a SliderStyle as an aggregator object. This helps API clarity for style manipulation since we can play with a single object reference that represents the component style, enabling to handle it atomically.
// Proposed Slider style usage
Slider {
sliderStyle: CustomSliderStyle { ... }
}
with CustomSliderStyle as:
// Proposed Slider style creation
// CustomSliderStyle.qml
// Aggregated style object
SliderStyle {
grooveStyle: CustomGrooveStyle { ... }
handleStyle: CustomHandleStyle { ... }
tickmarksStyle: CustomTickmarksStyle { ... }
}
or more compactly:
Slider {
sliderStyle: SliderStyle {
grooveStyle: NativeGrooveStyle { ... }
handleStyle: CustomHandleStyle { ... }
}
}
or even:
Slider {
sliderStyle {
grooveStyle: NativeGrooveStyle { ... }
handleStyle: CustomHandleStyle { ... }
}
}
This issue is only an idea only discussed between ourselves. It would be nice to have feedback about these API.
The isolated study of the scene graph internals (getting rid of QQuickPaintedItem), and how it could be used to create the new styles directly on it, didn't told us much in fact. Only that is better we keep doing these styles in QML and using Scene Graph itself to create sub elements that needs a more refined handling.
On the other hand, the Windows and Mac styles investigation was very important to decide our next steps. It showed us that these styles uses platform native APIs to draw the native widgets on each platform on pixmaps. So we would have to deeply study these API to create our own implementation of native styles using the scene graph. For these reasons isn't too simple to give up from QQuickPaintedItem some time to going deep on them right now since our time and head count is limited.
After the feedback from other developers, one of the main thing people want more is to have a widget set working with the native look and feel as soon as possible. Keeping this as our primary focus, we will left the restriction of depending on QtWidgets for now. So we will focus on having a working solution that can be easily replaced after. Fortunately, our proposed modular solution for styling fills that requisite.
git clone git://code.openbossa.org/projects/qtquickstyles.git |
| Current QStyle architecture |
// Regular Button having the underneath platform look and feel
import QtQuick 2.0
import QtUiComponents 1.0
Button {
width: 140
height: 40
text: "Native Button"
}
// Regular Button having the plastique look and feel
import QtQuick 2.0
import QtUiComponents 1.0
import QtUiStyles 1.0
Button {
width: 140
height: 40
text: "Plastique Button"
// This use case is not implemented exported yet, but it will be
style: PlastiqueButtonStyle { }
}
// Regular Button
import QtQuick 2.0
import QtUiComponents 1.0
Button {
width: 140
height: 40
text: "User-defined Button"
// Accepts a QML Component
style: Rectangle {
color: "gray"
Text {
anchors.centerIn: parent
text: button.text // button reference is injected when the internal Loader loads it
}
}
}
// Regular Button
import QtQuick 2.0
import QtUiComponents 1.0
import QtUiStyles 1.0
Button {
width: 140
height: 40
text: "Custom Style Button"
style: CustomButtonStyle {
background: "myButton.png"
pressedBackground: "myPressedButton.png"
}
}
import QtQuick 2.0
import QtUiStyles 1.0
Item {
ApplicationStyle {
id: appStyle
buttonStyle: CustomButtonStyle {
background: "myButton.png"
pressedBackground: "myPressedButton.png"
}
}
Button {
text: "Button with custom Style"
}
Button {
text: "Button with plastique Style"
style: PlastiqueButtonStyle { } // Theme changes doesn't affect when style property is set
}
Button {
text: "Button with appStyle"
style: appStyle.buttonStyle // Explicitly binds button style with a style
}
}
 |
| Proposal for a new QStyle modular architecture |
 |
| Current implementation for the style components |
ffmpeg -acodec copy -y -t $start_at -ss $ends-at -i $inputfile.mp3 $outputfile.mp3
