Differences between iOS and Android development

Android is programmed in C, C++ or Java, whereas iOS is programmed in C, C++ or Objective-C.

In a commercial point of view, Android seems to have a bigger market share.

People argue that iOS have better apps: all iOS devices have identical specs and features, disregarding resolution. It is easier for a developer to take advanatage of the whole screen, trust it will run smoothly... Android devices are different.

Developing Android apps for Android on Eclipse requires tons of module installations, AVD configuration. The default Xcode installation requires absolutely no complementary configuration. The app can be launched directly once the project is created.

Rhythmbox review

I've been using the music library software Rhythmbox for a while, and quickly decided to go back to Banshee. Here is why.

What useful features lack to Rhythmbox:

• Browsing music with album covers. (I read about Rhytmarty, but I don't know how to use it.)
• Seeing the cover of the selected track, not only the track being played
• Seeing the cover of a track in its properties!
• Stopping when song is finished
• Showing a track of a playlist in the library (like in iTunes) (lacks to Banshee too)
• Modifying metadata directly in playlists (lacks to Banshee too)

Bugs to fix:

• It stops playing when it fails to find a file (in DJ mode).
• If source of file not found, it plays selected.
• It indicates unfound files one line before where they really are.

A Prolog-based media search engine

I am currently carrying out an internship project consisting in a visual search engine. This made me think of how Google handled its image searches using the names and the descriptions of images on the web to match with the queried words. Here, images are only associated with clouds of words. So I thought, wouldn't it be better if they were associated with meaningful sentences that describe their content?

Prolog is in my opinion the perfect way to do this. We would create a knowledge base in the form of Prolog statements like height(img.jpg, 500). , shows(tree.png, tree). , uniform_background(tree.png). , background_color(tree.png, white). , etc. The downside is this would be a huge amount of work to do, so this task would probably have to be done collaboratively by the community of users (or Santa's dwarves). Then a query could be for example: shows(X, tree), background_color(X, white). and Prolog would answer that X is tree.jpg. The name of the images would in fact be their URL on the web and of course the search engine would be provided some rules to make deductions on statements.

Associated with a very good language analysis AI, this could allow users to make a search in the form of real sentences like "photo of a tree in northern England and a sunset in the background" and get very accurate results − better than if that sentence had been queried in a Google Image search. This could also help machine learning: bots would be able to make the text search they want, and use the results to learn how to associate an image with a statement regarding this image. In turn they would be able to generate statements on new images.

Idea of ​​genetic algorithm program

On a grid of pixels, we randomly create one or some of living beings represented by colored pixels.

One or some colored pixels representing food, or more generally a source of life is placed. Same for poison, or more generally a source of death.

Each creature has in memory an algorithm that directs its actions, and a memory where it can retain information, say an array of integers or booleans. Every time a creature comes across food, it eats it. Every time it comes across poison, it dies.

Possible actions:

• Write in a memory box. To enable the use of pointers, it may be advantageous to use the same size for the integers stored in memory as for the memory. Inputted values ​​can be constants, random variables, other variables from memory or external variables.
• Evaluate an expression containing an operator and one or more variables from memory. The arguments are memory addresses, and another memory address to know where to write the result.
• Move to one of four directions. (An instruction for each possibility) If you try to move around the edges, either you get stuck, or you are transported to the other side.

In the algorithm, we will have control structures:

• If, with a variable parameter in memory. If it is true, it goes to the next instruction, otherwise it skips this instruction.
• Goto parameter with the number of a line of the algorithm. (It is necessary to determine in advance the size of the algorithm.)

Possible operators (we won't use every one of these):

• Incrementation
• Decrementation
• Addition
• Subtraction
• Multiplication
• Integer division
• Modulo
• Conjunction
• Disjunction
• Negation
• Test of equality
• Test of inferiority
• Test of strict inferiority
• Test of superiority
• Test of strict superiority

Possible external variables:

• Current position (x and y)
• Position of food
• Position of the poison
• Position of congeners

If we only put one food unit and one poison unit, one can simply define their position. If we place more, we will certainly have to set variable names according to a number refering to a particular unit. But in this case the number attributed to a unit can influence the behavior of the creature, which is not very realistic.

We can also limit the available variables. For example, we can make visible only units that are in close range. Btw we can also limit the possible actions. (We already did it when deciding that creatures were moving to adjacent positions, whereas we could have had an instruction to move to absolute coordinates given by two variables from the memory.)

For external variables to be consistent with the memory variables, it may be interesting to define the dimensions of the universe with the same size as the variables.

When a living being breeds, the better for the program to move on is to produce a maximum of offspring. So let's say a new individual on each of the eight adjacent squares is created. All the children mutate.

Possible changes:

• Adding a new command anywhere in the algorithm
• Deleting an instruction
• Modifying an instruction, rather with small changes, for example just change a parameter

A convenient window manager

As a Linux user, I have never been a great fan of multidesktop feature. Whenever I put a window on another desktop I have to check all desktops before finding it. And I was often annoyed not to find an application with the Alt + Tab command, because that window was opened in another desktop. So I ended up not using multidesktops at all. Also, I find it's quite a pity that the only way to see several windows at a time is to resize them, so you hide a part of the content of the windows. Consequently to those dissatisfactions, I came up with this idea of a new window manager.

Let there be only one desktop but with variable minimum and maximum coordinates. On startup, it is given a default size.

On opening a new window, it is placed in the center. If there are already open windows, we calculate the center of the desktop and put the new window so that its center is the closest possible to the center of the desktop, without hiding another window.

Everytime a new window opens, we calculate its minimum and maximum coordinates, and the desktop takes as minimum (resp. maximum) coordinates the minimum (resp. maximum) of its former minimum (resp. maximum) coordinates and the minimum (resp. maximum) coordinates of the new window.

We dispose of keyboard / mouse controls to shrink or expand the size of the desktop, that is zoom in / out on the desktop, for example Ctrl + Alt + '+' and Ctrl + Alt + '-'. Another control would be used to translate the coordinates of the desktop, that is shift it, for example Ctrl + Alt + <Arrows>. Yet another one to calculate the minimum and maximum coordinates of the set of winodows and  define the size of the desktop according to them, in order to see all open windows at the same time, for example Ctrl + Alt + '*'. And finally another keyboard control to define the size of the desktop according to those of the window being focused, that is zoom on it, for example Ctrl + Alt + '.'. Of course, the moving and resizing of a single window would remain possible.

The wallpaper and the menus would stay fixed whatever the coordinates of the desktop are.

Every resizing of the desktop would be done with a smooth gradual transition.