Anjuta Python-Binding
20. March 2008
Sébastien put up a nice website for the Anjuta Python-Bindings!
No more excuses not to write plugins!
Anjuta 2.4
15. March 2008
So, I haven’t yet written about our new release, the first one that is included in mainline GNOME. Partly motivated by Miguels’s post on MonoDevelop (which would actually share a lot of code with anjuta in case they hadn’t rewritten all the libraries in C#) I will present the new and improved features. Some were already mentioned in an older post.
Editing
Code editing is probably the most essential part of an IDE. While it’s pretty unlikely to convert people using vim/emacs to an IDE we at least try to make people happy that have used IDEs on other operating system or are coding using GEdit. There have been plenty of improvements in code completion and auto-indentation in this release and it should work pretty well for C/C++ now. We always look for people to write language-support plugins for more languages (yeah, it’s easy…). This release also features the latest and best version of GtkSourceView.
In addition we also improved the way to quickly search in a file using the new “Quick Search Bar”. (c) of this is probably from the vim/emacs and firefox developers, but why shouldn’t we copy it if it’s good!
UI Design
With this release we made a big step towards better glade integration also thanks to the glade-3 developers. The old and ugly “Glade”-menu is now gone and instead the “File” and “Edit” menu items will now also work on the opened glade file. And the glade file is displayed like any other source file in the central editor window.
But there is still room for improvements!
Version Control
The Subversion plugin was improved in many ways and it a pleasure to use now. It gives you much better control over operations then the command line frontend. You can for example select which files to commit, resolve conflicts and view logs now in the GUI:
The great work on subversion plugin was done by James Liggett (who is looking for a part-time job in case you need a talented GTK+ hacker…).
Debugger
With this release, the debugger doesn’t suck any more. You can debug your code with nearly all features available from gdb, inspect variables, set breakpoints, set watches, etc. And it’s rocking stable now and should make your live on killing bugs much easier:
Thanks!
Thanks to everyone who made this release possible, especially, Naba, Sébastien, Massimo, James, Tom, Rob and all the translator who fought this 1700 string monster (and reported all these l10n bugs).
Future
Anjuta follows the GNOME approach to try to keep things simple and our Roadmap reflects that. The goal is to make the existing features perfect before adding yet another. Of course that does not mean we are not interested in new plugins. Everybody who wants to contribute is highly welcome, especially for supporting more languages.
FOSDEM and GTK+ bugs
26. February 2008
FOSDEM was great fun and I had a great time with Jürg and the Swiss Vala Gang.
Here is a photo from the “What you dislike” part of the GNOME wall (sorry for the bad quality):
Would be cool if the Gtk+ Hackweek would result in a fix.
And if someone wants to fix the anjuta top-crasher (which is a gdl/gtk+ bug), review the patch at bug #467698 – Thanks!
Update: I did not write that note but the bug number is #56070. Thanks to andre and ebassi for pointing out!
svn:externals for noobs!
20. February 2008
As I am usually far to lazy to RTFM I had to learn how to add externals definition to subversion the hard way. But as other might probably need it, too, here is how it works (mind the dot at the end…):
svn propset svn:externals "<directory name> -r<revision> http://svn.gnome.org/svn/yourmodule/trunk/your_directory" .
The problem is that after that command it will not work because you have to commit the property change first:
svn commit -m "Changed external property"
So here is the final example:
svn propset svn:externals "eggtoolpalette -r853 http://svn.gnome.org/svn/libegg/trunk/libegg/toolpalette/" .
svn commit -m "Added eggtoolpalette"
svn update
And now you will have eggtoolpalette revision 853 in your tree. Thanks to herzi for helping me solving this problem on IRC.
Ubuntu Packaging, Anjuta, Glom, i18n
29. January 2008
Joining the recent discussion about Ubuntu packaging policies I would really prefer if they would update their versions to the stable branch. For us developers it’s a lot of work to backport things to the stable branch and fix the major bugs in it. We do that because we don’t want to force people to use unstable versions and because the stable version has lots of users and therefore lots of testing. In general it is unlikely that a x.0 version will ever be released without some minor/major bugs because the development version has never enough testers and something will be missed. Anyway, we do more stable releases for the one and only reason that distributions can update their packages and give their users better software. If you don’t trust us that our new stable version won’t brake everything than we really can’t help you that much.
Anjuta 2.3.3 was released yesterday and this will mean that UI should now be frozen. We did a lot of bug-fixing in the last weeks. Thanks to all those people testing and reporting bugs and writing patches. Also thanks to my two GHOP Students, Philipp Kerling and Boleslaw Kulbabinski for their work and I hope to see future constributions from them. [EDIT] Forgot that I wanted to ask for some volunteer artists to have a look at #511000 and maybe also #510047.
In the meantime I have been working on the Glom drag & drop stuff for Openismus. Unfortunately there is still nothing that could be shown but be sure that I will post a screencast once it is finished.
There has been a lot of discussion about locking upstream translations in Launchpad. Many translation teams agreed here but we probably have to sent some official request to the Launchpad people. I hope that is no big deal as we usually have a good relationship with Ubuntu.
GtkSourceView 2.1 in Anjuta
5. January 2008
After Paolo Borelli, Paolo Maggi and others helped a lot in adding support for marks in GtkSourceView 2.0 (#487098), I was finally able to update Anjuta to use the new and much nicer version. The obligatory screenshot:
Please also notice the new symbol-db plugin on the right-hand side which is constantly getting better thanks to Massimo Cora’ and should be end-user ready within some weeks. We are also very pleased that OpenedHand is supporting us with a patch.
For those interested, I also opened a new GHOP task for anjuta.
Happy coding!
Dell Ubuntu Laptop
14. December 2007
Two weeks ago I bought my first real Linux notebook after my old HP nx6110 already was fully linux-compatible but still had Windows XP preinstalled.
So after booting up my new Dell Inspirion 6400 the Ubuntu installation wizard popped up asking me for username, password and timezone and I found a standard Ubuntu GNOME Desktop. As many others have already complained about, Dell did not install 915resolution and thus the display was 1024×768 instead of 1280×800 which was of course quite easy to fix. Until now, they still ship Ubuntu 7.04 but I hope they will update to the new version soon because it’s a bit like shipping Windows XP without SP2 while security updates are of course installed.
The next step was to update to Gutsy which is of course as “update-manager -d” and worked without any problems. I also enjoyed the new codec-loading featurs of totem a lot.
What works:
- Suspend-to-Disk
- Suspend-to-RAM
- All multimedia key except the rather useless “Media Direct” key which should launch the laptop directly into (Windows) Media Player
- WLAN
What not works:
- After Suspend-to-Disk NetworkManager hangs
- After Suspend-to-Ram sometimes the keyboard does not respond (sleep and wake-up again usually fixes it) and in rare cases the display is not switched on.
In general quality and battery capacity seem very good and speed is ok as well as the low price. I hope Dell will improve Linux-integration for the next models to get a good out-of-the-box Linux feeling.
Hardware applet
19. November 2007
When playing with my new bluetooth hardware I was very pleased that it was supported out of the box. Anyway, I also missed something that would give me some indication that the hardware is working. (e.g. the first I did was to check dmesg)
When you look a Windows, they have those tiny notifications telling you that the new hardware was detected (or that it is not working or whatever). I think we should also have something like that. We now have HAL und dbus and I shouldn’t be that difficult to implement though I have no idea how this works in details. So take this as a proposal or tell me that it already exists (I didn’t find it):
There should three modes of operation:
1. Hardware is plugged in and supported
- Tell the user “Detected xy – new hardware is now working” (alexl pointed out that we should not do this as it is obvious. I would prefer to have this notification for the first time the hardware is attached).
- Propose some common operations: Open files for an USB-Stick, F-Spot for a digital camera, gnome-scan for a scanner, etc. Of course with a notification and not with an ugly centered dialog like Windows.
2. Hardware is supported but needs configuration
- Show enough information that the user can complete the configuration
- If there is no wizard to do this in a user friendly way, at least point the user to a (distro-specific) tutorial or at a place where he/she probably could find help.
3. Hardware is unsupported
- Point the user to a distro-specific update tool to search for a driver (=> PackageKit comes in mind…)
- If there is really no driver, ask the user to report a feature request, based on the device id. This should be saved in a database to see which drivers are needed by many people.
The most obvious case are of course USB devices but maybe also stuff like pcmcia and bluetooth could be detected that way. I think this would make hardware support on linux a lot more user-friendly. Personally I neither have the knowledge nor the time to implement that but maybe someone likes the idea!
Blue your teeth
17. November 2007
Yesterday I finally decided to give Bluetooth a go and bought the cheapest available USB adapter at the local electronic store. I must say that I expected it just not to work at all on Linux or that I would have to spend the whole afternoon to get at least some things working.
Anyway, I just plugged in the adapter and checked dmesg to see what happens. To my surprise it just told me that the driver was loaded and the bluetooth stack was now ready. I fired up the gnome-bluetooth-applet and clicked on “Browse Device…” to just see my mobile phone being detected and connected to it. I could not browse the files at first because the gnome-vfs-obex module was not installed but installing it fixed it.
After being able to browse my files I wanted to check if there is a way to sync my phone. After I checked that the phone (Sony Ericsson K530i) does not support SyncML I did not really expect to get anything going.
But as I wanted to give it a try for a long time, I first migrated from Thunderbird to Evolution to have a PIM-Suite and to have syncing support at all. Migrating is actually a real pain because you have to import all your folders manually but in the end it worked out. I have used Thunderbird/Netscape my whole mail live (about since 1994) and I still think that it is a good mail client. But Evolution is really better integrated into the GNOME Desktop and it has improved a lot since I last checked in those old 1.4 days. It could be a bit faster though and I found a nasty bug for people using small screens like me.
So back to syncing: I installed multisync after googling a bit what I need and added a synchronisation pair with Evolution and an “IRMC Mobile Device” (guessed that because some other Sony Ericsson phones were in the list). After clicking on “Sync” I expected an error message but instead the phone just synced.
So thanks a lot to anyone being involved in those Bluetooth and sync stuff – it’s really great!
Anjuta’s way to 2.4
2. November 2007
With the first beta relaese 2.3.0 today, Anjuta moves one step forward towards the next stable release which will bring lots of cool and long awaited features. So here is the promised summary of the new and coming features:
Glade integration
For integrated glade we used to have a very ugly “Glade” menu which consisted of the items usually used in an “Edit” menu but just for glade. This was very confusing because “Edit->Undo” would not undo the last change you did in glade but the last you did in the editor.
In trunk, the glade designer is integrated like any other editor in Anjuta and all items can be accessed with the “Edit” menu which always works on the current focused document.
Before, someone asks, if you want more Visual Basic fealing, take a look at this bounty.
Coding support
Our autocompletion and calltip code has been vastly improved for both editors. It can now show several tips at the same time if appropriate and should work much more reliable. This is of course not yet the end of the road because we want to have this for more languages (Python comes in mind) and we want to detect some more use-cases, like members and object methods. This will depend on the new symbol-db plugin (see below).
Auto-indentation should also work much better now with both editors, is configurable and can also auto-detect the settings from a mode line.
Quick search bar
Incremental search has sucked a lot in anjuta for long. To improve this we borrowed the idea of a search bar from firefox and I personally think that this rocks. Of course there is still a full featured search dialog and we are also planning to improve that one.
New symbol database
This feature is not yet available in the release but you can preview it in svn. The idea is to save all the code symbols which are parsed by ctags in a sqlite database (accessed with libgda) to allow much better code navigation and completion. Massimo already did a great job there and I hope that this will be ready for 2.4.0
The screenshot shows a file from the gimmie project with the class hierarchy. As you probably know, gimmie is written in python so the other advantage is that this will work for many languages and it might also be possible in the future to use other data sources apart from ctags (you know what I mean, Sven?).
What else?
Apart from those cool features a lot of bug-fixing work happend, especially in the debugger. We have a lot of great new icons and some still need to be integrated into trunk. HIG-stuff was also partly fixed though there is still room for improvement.
Other crazy ideas
Of course we have more plans for 2.4.0. This includes better version control management with integration into the file-manager, supporting more languages. We also want to migrate to GtkSourceView 2.0 but that will mean that someone (or myself) has to find time to add a new markers interface to GtkSourceView. And for all those Vala enthusiasts out there of p.g.o, yes we also plan to support Vala but it will at least depend on GtkSourceView 2.0 and either vala support for ctags or some other (reliable) way to get the symbol out of a vala file.
I am also glad to see more people willing to help out and ask for help with writing plugins!