FTP news: Threads and Windows

After a long silent hiatus, now some good news!

Development proceeded, but I did not announce anything since the code was too buggy. Two were the areas of change since the ancient 0.1 release: threads and socket core.

I want FTP to have a worker thread during file transfers, else the user interface is unresponsive, which is barely acceptable on the Macintosh and unusable on GNUstep, where there wasn't even a progress refresh. My first attempts called the gui from the worker threads which gave problems on GNUstep. Now with DO, the controller separation is need and works very well.

I rewrote the core data transfer mechanism, which previously was in typical BSD style where sockets where used as standard files, which a more portable recv() approach. Together with some tweaks and macros this means that socket operations work on Windows!

FTP is thus now able to work on windows too, I attach a screenshot.

Sunday Evening (AlemanniaStep)

Thus it came to an end, AlemanniaStep, that is. Thanks to a prepared schedule of topics, the short time was exploited well. We had an interesting demo of the development of various handheld devices by Nikolaus and we had some discussion about how to market ourselv better, how to improve the SoftwareIndex and our problems with packaging in distributions.

The rest was dedicated to hacking (as we see in the Picture, Fred fixing weird Font stuff that SWK triggered). Fred and I fixed the backend and Terminal bugs, Nikolaus hacked on SWK and I tested it on both Mac and GNUstep providing continuous feedback and it indeed improved.
Another session was dedicated to porting and checking of FlexiSheet, which we got finally compiling on the Mac, although with some compromises. Although not ready, it is foreseeable to adapt some pieces so it will run under GNUstep. Gerold found some issues with PCH on debian and made a good proposal in improving FTP after testing it.
These activities consumed quite some time, thus there was little time for windows. Also because one of the bugs didn't reproduce as expected.

I'll write about results in the next future, when they get a bit more finalized.

AlemanniaStep

Here we are in Freiburg, with Fred, at AlemanniaStep. Few people came, but those that came are good. Let's hope in a lot of new ideas, bug fixes and development.

Fred, Gerold, Nikolaus and Riccardo

New LapisPuzzle

LapisPuzzle 1.1.0 is out! The work of Banlu badly needed some updating since it was no longer usable. Matt Rice hinted me about what was wrong and I took the time to complete a better key event handling [NSEvent characters] instead of codes.
I also updated the Makefiles and now LapisPuzzle works on Windows, like the screenshot proves! Our Windows backend and port is actually in better shape than some people say.

SystemPreferences 1.0.2

Finally SystemPreferences got released. Long due it contains a series of minor corrections since the past release of 2006: Updated makefiles against gnustep make 2 series, warning fixes and compilations on older platforms like gcc 2.95.

But maybe of more impact is the new Color Schemes module, written by me, which allows the setting of the color accent of GNUstep. It can select against ready made schemes and has a simple built-in editor. The schemes are compatible with backbones Preferences' application.

Included is for example the "GNUstep lighter" scheme which is visually very similar to the standard NeXT style colors but they are brighter: it is thought for people running their monitor with a different gamma than NeXT computers. It appears to be the majority since there were a lot of complaints about GNUstep being too dark!
If you run GNUstep applications on Windows I bet you will welcome this small new detail.

Browser and WebKit progress

Thanks to the continuous dedication of Nikolaus who worked and works on SimpleWebKit, a new, pure Objective-C WWW implementation compatible with Apple's WebKit implementation. It shows once again the real power of Objective-C and the Foundation and AppKit frameworks (and also shows what kind of unnecessary kludge Apple did).

Thanks to the efforts of Fred, Nikolaus himself, Gregory and me, SimpleWebKit and GNUstep AppKit evolved enough so that SWK can now display pages pretty decently, close to what the first screenshots from a mac showed.

Images, links, font size, rudimentary Header and list support is there. Horizontal rules. Bakcground and Font colors.

Also the DOM tree is pretty complete, so parsing is even more advanced than the display itself.

Thanks to the power of OpenStep Vespuccci already supports easily multi-window browsing. And scrolling inside the pages thanks to the scrolling of text views which Fred fixed.

The way to something usable is still long. No history, no tables, many small quirks even in basic 1.0 HTML when doing formatting.

But what counts is I think that an extremely big step was done. I was amazed when I saw everything working so smooth.

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.