The cache behaviour for each language plugin is still the same as before, because the procedure is partial very different. However where I could find similarities, I merged the code to the new parser-engine plugin.
From time to time it's a little bit troublesome. For example yesterday the editor didn't show the proposals for the word, which I started to type. I searched about six hours to find a solution for the problem. Finally I read the source code of given methods, which I used in my code and couldn't find any documentation. I found out what each method does exactly and could solve the problem.
I hope that I finish my work on merging the language plugins very soon and devote my time to the real work: the clang plugin.
Did you ever try to work with the Gimp with Ubuntu's global menu activated?
It doesn't work! I try to open the menu and fail so literally everytime because it's not there when the tool windows have the focus. However you will notice that when you already moved the mouse all the way up, because the f**king thing is hidden as long as the mouse is not over it.
I seriously hate this thing! This is the work of morons who do not use the computer for actual work. I have no other explanation for that.
For everybody like me, who believes window menus should be in the window they belong to:
sudo apt-get autoremove appmenu-gtk appmenu-gtk3 appmenu-qt
From now on this is the first thing I have to do on every Ubuntu machine I use.
This message was brought to you by the minstry of rants.
As part of merging code and unifying the behaviour of each language plugin I improved the Vala plugin. Calltips show method names and return types now instead of only the parameters of the function as it was before.
The Python preferences before and after
Additionally the vala plugin has its own preferences widget now. Before it used the preferences of the cpp-java plugin. As a consequence the Vala plugin no longer depends on the cpp-java plugin. While doing this work I learned, how I can integrate C interfaces in a plugin, which is written in Vala.
But the Vala plugin is not the only one which got an update. The Python plugin has the "Add ')' after function call autocompletion" option now. With this new option the Python plugin has the same functionality as the other language plugins and so I made the preference widget looking like the preferences widget of the other plugins.
Moreover I added the new behaviour of C/C++ in Python and cleaned up the Python plugin a little bit for example of deleting unused variables.
Last week I learned how autogen works. Therefore I had the ability to adapt the new parser-clang plugin so that the plugin will be only build, if llvm and clang are available on the system. Otherwise it will be ignored by the compile process. After this work I played a little bit with clang. Once you know the way of working of clang it's very easy to program with it.
This week I continued with splitting language plugins in a parser part. The language-support-python plugin does nothing other than operate with rope. And at first view this is also the same case at the language-support-js plugin. So splitting these two plugins makes no sense, because after that, there is no basic plugin left in the basket, which we can use as a language-support plugin. The Vala language-support plugin has some dependencies on the parser part, which are not trivial to solve.
Hence I stop splitting the language-support plugins and finally I split only the language-support-cpp-java plugin. The new interface for the completion engine is called IAnjutaParser. So I integrate IAnjutaParser in the Vala, Python and JS language-support plugin now. Only C/C++ has its own parser plugin and consequently not the language-support-cpp-java plugin, but the two parser plugins parser-cxx and parser-clang integrate the IAnjutaParser interface.
Last weekend I began to split the parser part from each language plugin to a separate plugin. In the future the parser is going to be used as an adapter by the language support interface. This makes the code more uniform and I hope we can merge some code.
All in all the language-support plugins shouldn't manage any more the own parser part, because they can access a common parser base. Now the parser plugin itself decides which parser is used, which is then only loaded if the corresponding programming language is used.
In the last days I learned how interfaces works under Anjuta and C. Until then I only knew it from Java.
By the way you can take a look at my current code on github.
Split the language-support-cpp-java plugin in an indentation-c-style plugin and a language-support-cpp-java plugin without the indentation part
Read the documentation about the plugin system of anjuta
Splitting the plugin took more time and was more challenging than expected. The main problem was to understand what each method does. So I had to read much documentation. I'm not already done with this work, but I'm on a good way…
I'm accepted with my proposal on Google Summer of Code for this year. My mission is to bring clang magic to Anjuta. "Anjuta? What is Anjuta?", maybe you wonder yourself now. Anjuta is a IDE just like Eclipse.
Clang is a compiler front-end for the LLVM compiler. With this compiler front-end for C, C++, Objective C and Objective C++ code we can get better results in Anjuta. For example if you make a simple mistake by writing code Anjuta will warn you. This can save a lot worse.
The first major obstacle is to make thoughts about the future architecture of the language support interface, so that you'll be simple load plugins for a language feature like autocompletion or indentation. To support this purposes I'll split up already available language plugins in an indentation part and the support part.
Since version 11.10 Ubuntu has a feature called Global Menu. This means, that window menus don't appear in the window itself anymore but on the very top of the screen in the so called panel. Have a look at the video to see it in action:
I have the impression that Ubuntu's UX designers are trying to mimic Mac OS X here. However, there are several problems with the solution they came up with. The Mac shares some of them, but some are specific to Unity.
The Global Menu wants to give more vertical screen real-estate to the running applications by having only one menu bar taking up space for all windows together. On netbooks this may be a usefull thing, but on computers with HD everywhere nowadays this actually makes usability worse. The Global Menu makes you "travel" large distances with the mouse from the window to the upper border, which can contribute to repetive strain injury.
Another problem is that the menus are not visually connected to the window or application they belong to. For first time users it can be hard to grasp that the menu even belongs to the window or application that is currently in focus. On first sight it looks as if the menu contains global functions. OS X and Ubuntu both try to fix this problem by showing the name of the application at the left most position.
However, Ubuntu has another big usability issue adding to the previous point. It hides the menu and only shows it when the user hovers over it with the mouse. First time users will probably have a *very* hard time even finding the menu at all. In my opinion this is the biggest glitch of them, because you can't find the menu, without knowing that it is there in the first place and moving the mouse up there. I think this is called a vicious cycle.
To make things worse, I don't even see *any* reason why one would hide the menu, as there is oviously enough space to display it all the time.