Watch your CPU

TimeMon, the CPU monitoring application popular on OpenStep runs now on NetBSD too. I added the necessary code to the GNUstep port, which is found inside the GAP project .
Porting involved using the correct sysctl calls (in true BSD philosophy, as opposed to the Linux mess which involves reading and parsing files!)

No, I didn't add myself to the list of the porters. Not yet.

Live from AlpenStep '07

We are enjoying a nice time in Les Marecottes where we are holding our first AlpenStep meeting. On topic are hacking, discussions and presentations about the various projects. Bug fixing was great, but the highlight was the GSCake. Please check the attached photo with Gerold Rupprecht, patient organizer of the whole event, and the excellent instance of [GSCake initWithFun]. Subclasses of the GSCake object are allowed, but please send us the instance for compliance certification.

We had a presentation from the Etoile and their frameworks, simplewebkit bug smashing. Extremely geek was the new OpenMoko Neo which Nikolaus brought.

Members present were the busy organizer Gerold, gui maintainer Fred, etoile developers Quentin and Nicolas. GAP was represented by me. Lars was present too, Gürkan felt unwell unfortunately and left earlier.

Spin, spider, spin

Hard work in the past month of a couple of programmers brought a rendering engine and a browser for GNUstep a step closer! Currently most of the limitations SimpleWebKit had compared to myStep are solved! Quite a bit of debugging went into Vespucci too as it is being refactored in a document-based application capable of displaying multiple pages at the same time. Equally merit has to go to Richard who patiently helped to improve GNUstep's core to handle URLs and the HTTP streams. Thus the text you seen in the screenshot is actually downloaded from the Web, not just a mere static string. Although several problems still remain, you may notice that there is lready some font rendering and that the Horizontal Rule is rendered correctly!

The keenest of you may have noticed another detail! The whole application is running on Microsoft Windows! The build process needs to be manually tweaked, but a working executable is possible. It works worse than on Unix though: images represent a problem.

I was really eager to display our progress, but held it back a bit until some details were solved.

The spinning spider

Some interesting activities cook inside GNUstep and GAP projects! Dr. Schaller is working actively in a WebKit implementation for myStep. Now I and Peter Cooper are helping him to bring the Framework into GNUstep, it already compiles! Although a lot needs to be done and SimpleWebKit may never reach the completeness of Apple's implementation I still think it is an interesting task and a total objetive-c approach should not only prove the power of the language but also give us advantages in the future regarding efficiency and customization.
As soon as the framework compiled I started the development of Vespucci, the program that will be GAP's Browser. The screenshot shows the debug output of the Current WebKit, interpreted really from a simple HTML string.
Maybe after the failure of the original port attempt of the WebKit by means of wrappers, this is the first screenshot of a GNUstep Browser? Stay tuned!

The double-face of GNUstep

Yesterday I had a long call with Gregory and we smoothed out many details about what GNUstep is, where it is and where it should go.

I noticed really a lot of confusion about what GNUstep is, everybody seems to have his own ideas, some of them are indeed correct but just a part of the whole pictures, others are just plain wrong. This ambiguity doesn't help us as a project, it confuses the prospective end-users, it confuses potential developers and also stirs up quarrels and useless polemics inside the group.

Thus I may sum up what I consider GNUstep is: essentially I see a double use of GNUstep: the base for an environment, a workspace inspired by OPENSTEP and a cross-platform, portable framework that enables developer the deployment of their application on Unix (Linux, BSD, Solaris...), MacOS X and Windows. I consider these goals absolutely not conflicting and they should be both taken care of; furthermore one reinforces the other.

As an environment GNUstep needs to offer a working framework which is solid and well working on most of the major Unix systems. Features that some people could find useful refer mostly to the look and feel, a comprehensive set of applications and utilities (either provided by the GNUstep project, or, more aptly, by affiliated projects like GAP, Backbone or Etoilé) and their integration.
People who see in GNUstep an OS should find what is needed by this environment and supply the remaining by themselves.

A framework that enables portability needs to work on more operating systems and needs to be even more flexible: it needs to be able to blend in to the Look and Feel of the host OS (as an option of course) but it also needs good ways to deploy the application; for example if the installation of more GNUstep-based applications is intended, the installation of the framework plus the different binaries should be an option, while if GNUstep is used just for one single application, everything should be self-contained and GNUstep itself should be unnoticed by the end-user.
If a Desktop Application of a certain project can be considered useful standalone, it shall prove interesting to support it both as part of the Workspace as well as a single application ported, say, to Windows or Mac.

I feel positive about the GNUstep project offering a set of applications, like it does now, which could be considered as a reference implementation. What should be taken in account by the developers is never ever to take the existence of these applications as granted: this would make a real portable core impossible. These application should be considered an option and other projects shall be able to replace one or any of them. Still, their sheer existence should prove the point that GNUstep is more than a mere toolkit.
At the current state of things, there should be no official appointed "Desktop Project" and the end-user shall be granted the freedom of choice

Your distant desktop

Need to access your remode desktop on windows? rdesktop is your tool. Since it is tedious to remember every time all the command line options to specify the server and username, a small interface is a nifty think. Xfce and Debian isntalled me a working one, but I do not like the look of it, it has several bugs and quirks.... and it is GTK2.

So, let's objective-C, Gorm and in GNUstep and a small working app popped out. It is usable already and I wills oon release a 0.1 release, in GAP, I hope other people will like it too. The CVS is already public.

Of course, several features are needed to make it top-notch, but they will follow, stay tuned.

more native xlib awt stuff

Woah! I hacked in kaffe awt up to deep in the night. The rendering of strings inside textfields was broken since a long time! The cursor and the typing was wrong, once enter was hit it worked.
I didn't have big hopes to fix this and I just tried to have a quick look. I discovered that the java part considered the fonts fixed width even if it wasn't and thus returned the wrong charWidth. Without much understanding and even lesser hope I messed inside the native methods!

I was able to understand the faulty logic and implement a new one by accessing the XFontSets and font structures. I queried my first X Atoms!

Although my implementation now is not very robust I think it is definitively correct and now the character width is computed correctly.

The lack of robustness is due that I take the first font struct of a fontset, from a XOC.

in the compulsory screenshot our AWT is running happily on Darwin X11 on MacosX 10.2.8... you may notice how nice the text fields and the file dialogs are!

more swing

I was able to fix further problems in the kaffe AWT ilpementation and to integrate it furthermore with classpath.
Radiobuttons do work now and menus started to be usable too! Most Layouts seem correct too.

Unfortunately some other compontents (like the tabbed pane) still don't work and I don't know how to solve the problem.

The attached screenshot shows the portability of a swing that uses directly X11: it is running on Irix on a SGI Indigo2.

Kaffe AWT news

I spent the past weeks in the effort to remove some cruft out of the Xlib peerles AWT implementation in kaffe.
Why? I would find it very interesting to be able to run at least simple swing programs without the need of the weight of QT4 or the GTK2 bloat.

As you can see in the screenshot, the effort paid off! Simple swing programs start and simple events like the JButtons do work! The JTree is fully functional and scrolling of the pane works too.
You can also see that AWT still works as I opened a locale properties program I am developing, you can notice the awt drawn toolkit buttons and file panel.

My work was tries to leverage as much as possible from classpath, which kaffe has anyway. Thus I totally removed some classes from the kaffe awt so that the classpath ones are used (copying the files over as was done in the past is a lot of work and also means that with the time those classes will get out of sync with classpath again).
I also refactored some AWT classes so that the fields and methods are more compatible with classpath and JDK serialization.

A lot of work remains to be done though and I'd appreciate any help.
Roman Kennke from classpath was very precious in helping me out of some pitfalls and he is himself working on an pure X awt, but his one has peers and accesses X directly through java using escher. I think that too is a promising project and I hope in a future collaboration.

A GNU World. GNUstep on Hurd

Yes, The title says it all.



Take the latest-and greatest unstable, unreleased GNU Hurd from Debian (this will give you an improved libc and thread library that doesn't require certain hacks to make some un-Posix code to work). Install it (and cross your fingers). Install of course the objective-c compiler. Install the necessary dependencies (libxml2, libpng, ffcall) witht ehir developer headers.

Then get the latest GNUstep. Configure and install make, base, gui and make. I used the xlib backend.
Now some caveats: the base library needs to be hacked. More specifically, after you have run configure, modify Sources/config.h and define BROKEN_SO_REUSEADDR to 1. Also I experience some troubles with the daemons of GNUstep, not only on HURD but elsewhere too, thus manually start gdomap and gdnc.
Now you are ready to start your applications! install one, run "make_services" so that it is registered and then launch it with "openapp NAME" or "gopen NAME.app". Inside the gnustep repository there is the workspace manager (a must have, but currently it crashes here) a small RTF text editor Ink (favourite small app to test if GNUstep is working...) and there are many nice applications in the GAP project and from Backbone.

If someone doesn't believe, check the screenshot... FTP is connected to the gnustep site and Ink is typing well...

So the edges are a bit rough yet. But it starts to be there, I'm excited.

new RPMs for GNUstep

I worked hard and had to do quite some tests... but I finally got new RPMs for GNUstep and its applications, they represent quite an improvment over the last version and I have also added applications compared to the last time.

The packages and source pakages are here.

As always the packages are made with MkLinux in mind, but I made them more general removing some weird hacks, thus I think they will work on more distributions, especially if starting from source.

I put all applications and tools in their own "GNUstep" category now.

Apart from several updates, I have added TextEdit, Terminal, FTP, TimeMon...

Thanks to the patience of its developer, Andy Ruder, TalkSoup was made compilable on gcc 2.95 and thus is available for MkLinux too!!

The great apps that are missing are GNUMail, which compiles and runs but has then problems finding the Inbox folder, and ProjectCenter which compiles bug segfaults on Mklinux. Both applications work on my Gentoo system instead. If someone has hints... let me know

Try the source RPMs out at your place!

New releases for GAP

This weekend Battery Monitor 0.2 and FTP 0.1 were released for the GNUstep Application Project. I hope with this small contribution to help out a bit the GNUstep problem which is, in my opinion, also a general lack of tools and applications.

Battery Monitor checks ACPI and to do this peeks inside the /proc file system. Once again working with it makes me thing on how weak and bad the idea of files versus syscalls is. I am forced to parse files with a useless overhead. Furthermore linux did also a very poor standardization effort and the /proc/acpi changes from laptop to laptop as well as from kernel to kernel version!

Also I have a worried thought for the future, I spread myself thin over a couple of projects now, all of which I think are useful. As I fear to get more busy in the future and as I hit some problems in the current design of the applications, I seriously fear that without external help and collaboration the projects are going to stagnate and be left unfinished, which would be indeed a pity. But it once again reflects another aspect of the GNUstep community.

This also reminds me to tickle Nicola again about the possibility to use kaffe with JIGS! Java integration can only do good to us.

Zeta and BeOS

Yesterday and today I tried Zeta, the successor of BeOS by YellowTab, on three different computers. The impressions are mixed. One can see that yT put a lot of effort in it. It runs now fine on a centrino and recognizes it 10/100/1000 ethernet card. The overall impression of speed and usability is fine. I dislike however the GUI changes that were done, I think they are only for the sake of looks (the highlight in the menus for example, the scrolling pane at the left in the new preferences application and other similar details) and which also clearly affect speed. On a Pentium II one can materially see those "new" widgets redraw (especially the menus) in a quite unacceptable way: even gtk on freebsd is faster on that box. Many applications themselves impress with their speed and typical BeOS style (like the email reader for example or the old but trusty Netpositive). Startup times are often negligible. The Gobe office suite is nice and light. Thus all-in-over I think there is improvement although the whole picture is "patterned" between old and new and slow and fast in performance. I hope yT will offer a real "old school" fast theme again (the current one isn't good) and fix perfomance issues here and there. Once notices "non native" applications like Firefox quite immediately for their slower speed and slightly different look (but this could open a big discussion for most platforms). The new joined preference panel is a good idea (except for the pane at left) since now settings are clear and grouped. The old-style system, very reminiscent of old Macintosh times, isn't handy for managing many settings.

On the Unix flavor side... the experience wasn't so good. I tried to compile jikes and it aborted compilation with some wide-char type problems (possibly a jikes problem) and then pico server (http://pserv.sf.net) which aborted compilation due to missing unix-style sockets. Thus for now I can't do any testing on how kaffe would work here...

gnustep on gentoo fine again

Thanks to the fixes Adam made with libgif and linubgif, core GNUstep compiles fine again on gentoo. I had to recompile/relink all applications (I don't thinkn this is nice, if the dependency is brought in by a library). Enrico also fixed also GWorkspace to compile without DBKit.. so finally the whole environment of base applications is in good shape again.

feeling like a bug...

(the post was mysteriously lost, so I try to write it again... and of course it didn't came out the same... some of the initial feeling was lost as I thought about it again)
I watched a video by Alan Kay [ part 1 ] part 2 ] and it made me feel small and bad. And it was not because of some nostalgia that sometimes creeps up my back when I see stuff from the pioneering time of computer science. I was impressed what was done in those times! And some things can't be still done today such easily

Maybe the most impressive thing were the small programs written by children! They were nice and stimulating programs and I would have a hard time doing something alike with the tools I know (even using languages as Objective-C or Java), really! And those kids wrote one or two pages of code for drawing programs with interactive menus and design constraints? I think that controlling the computer and being able to program it is very important and today, even after almost 20 years of programming, I feel it distant and unnatural.


Another interesting thing were the interfaces. Today due to use of the Mac and the interfaces derived from IBM's CUA (motif, windows, os/2) and theyr blind clones like KDE or GNOME limit our perception. OpenView would be regarded strange (not to speak of Amapi's natural interface).
The interfaces of the programs presented tehre are instead very clean and present concepts that aren't used much today. The Alto programs striked for example with the non-intrusiveness of their menus, the modeless use... but also older programs were interesting in their use. The direct manipulation of objects in the Rand program reminds me a lot of the Newton.

We have now very powerful hardware and operating systems, but their programs run at reaosnable speed on their systems... while today often we think about excess in functions or eye-candy... and less about usability. Also thing pile up. The interface to write this blog isn't as nearly as intuitive as the text editor on the Alto was (well... it also lost my first blog entry). I write inside a browser which handles dynamic contents... the browser runs on the OS itself. The result is miserable, even if a lot of power is "stimulated" little power is "unleashed".

One last thought is about the use of the computer in education. I feel warm and cozy that Alan thinks like me: an important liberal art is important. (I translate this into: teaching to use Office in elementary school is horrible). Also kids could be teached a much more creative use of the computer as the Alto examples show. When I was 14 years old I was tought LOGO, now people at high school learn visual basic... I think I was better off! Much better!

gap comes along...

Thanks to the keen help of Robert and Gregory I was able to fix so,e s,all but annoying bugs in both FTP and Graphos and thus both applications made a further step towards usability. I think that FTP is almost ready for a first "beta" release, I am waiting for some feedback, especially bug reports.

Kaffe on Solaris/Sparc

Good news! I compiled kaffe on sparc solaris 2.6 using JIT and pthread on my dual-processor box... and yay all regression passed! included te 4 jni tests. I have never seen this on that box since years. Cheers!

Kaffe on Darwin

Kaffe on Darwin is fine again, using interpreter and pthreads. It passes all regressions happily.

last night efforts... wx and DOM

I continued my effort to shape wxMotif in a better form on IRIX but until now no real progress... The code is ugly and although Vadim (vadz) was kind to me and spotted various methods to improve... the output was still none (ok, apparently I didn't break anything either).

The other interesting discussion I had was on IRC with Stefan. The problem is again the lack of applications in some areas and the quality of others. Today's menu was "browser". Apart from the usual talk of porting other engines... the idea of writing our own rised up again. ANd this one it seems promising.
We should start the browser work in making a sort of webcore. That one should be based on a DOM renderer, so that the translation of XML, HTML or whatever into o a DOM can be a separate module. Help in this regard could come from the Iconara DOM framework and the expat library. Makign a simle XML parser should be easy with these tools and so we could concentrate on other issues like the rendering without loosing time in the parser. Once the foundations are set, an HTML->DOM plugin could be done and added inserted into Iconara. Also this approach would force us into a good separation of tasks and thus in the future even iconara itself migh be replaced.
If this talk will have a future I don't know, but I'll think of a project code-name!

The beginning

Everything has a beginning... and so also my blog. After different people showed interest in a potential blog by my side, concerning mainly my open source activities, I decided to create one and see how well I come along with it.
I do not promise regular updates... nor is the life of this blog guaranteed.

I assume that the main focus will be on my development activities in Kaffe, GNUstep... and possibly generic comments about my visions of the world of computing.

Maybe also comment on my current music, photography and vision of the world will find a way here... we shall see.