Porting applicaoitns
 

Ok, I'm new to the N-series platform (haven't got one yet, but have been playing with the dev kit / emulator). However, I'm a long-time Zaurus user.

Question on porting apps. From looking around the various forums & mailing lists, there are a lot of comments about various missing applicaitons. Since Maemo is basically a vanilla X11 system with a regular window manager and standard GTK libs, what issues do people have porting regular Linux apps over to the N series? Is it due to the need to convert apps so they are usable on a tablet device (i.e., no right-click available, and mouse-moves-with-click-only)? Or is there additional customizations needed to get apps to recognize the Maemo input methods and desktop semantics (task bar icons, menus, window management)? Otherwise, what is to stop one from grabbing the varisous source packages from Debian ARM and re-compiling them under the dev kit? (including using debian package dependencies to automatically pull in any missing libraries).

As for resource constraints, if you look at Meanie's Zaurus page, there's a bunch of heavy X11 apps that's been compiled to run under the various X implementations for the Z, including Gimp, Openoffice, the full Firefox, etc.

If the main issue is getting everything blended into the standard Maemo interface, then how about this idea: Put together a bunch of applications that assume a standard window manager / desktop environment. Then when you want to run these apps, simply run them under X-nest, which would have it's own window manager running. Now this environment would only be kicked off if you are using the N800 in mini-workstation mode, hooked up to a usb or bluetooth keyboard & mouse.

The way I envision it is that you'd have a desktop-style Linux system installed on a large SD card. When you insert the card, have it kick off X-nest, then start up a light weight window manager in a chrooted environment (if needed), where everything within that window would follow a standard desktop metaphore (so you could run OpenOffice, full sized Firefox, etc). Then there would be no complaints of missing applications, even if some of the apps aren't suitable for using in palmtap/tablet mode.

Re: Porting applicaoitns
 

The problem is that the tablet uses an ARM processor. Most apps are set up for x86 processors.

Re: Porting applicaoitns
 

The window manager is not a "regular window manger" it is matchbox, and the gui apps need to be "hildonized" to integrate properly into hildon framwork. "regular window managers" are available, ports of window maker, openbox, xfce, KDE, have been on tablets in the past.

Re: Porting applicaoitns
 

I realize that this exposes my naivite, but would it be possible to run another window manager inside Hildon and only run that Hildon 'application' maximized so that the inner window manager gets access to the whole screen?

Re: Porting applicaoitns
 

Well this is an interesting question, and I think it would be nice to see a development of such a window manager. I attempted and I can start hildon menus and status bar up on alternate window managers like openbox and KDE. The probelm is it seems to have some kind of hooks into matchbox to hold it in place along the left side and the status bar is also not displaying in the correct location. I have tried at least 10 window managers and they all dont display the hildon menus properly. If we could have such a window manager we could co-exist it would be awesome.

Some type of crossbreed matchbox and normal window manager would be awesome, but I think it would have to be built from scratch. Sounds totally possible, but not by me :)

Re: Porting applicaoitns
 

That's why I mentioned running xnest or something like it (xoo, xephyr). It runs as an X client app, and in it's window it can run an isolated X environment (it gets it's own display number). As soon as I get my device, I'll try compiling xephyr for it, then see if I can get an entire environment running under it (similar to running X/QT Jumbo Package available for the Zaurus).

I was thinking more along the lines of using the Debian ARM repository. If there are differences between regular ARM and the ARM-based cpu in the N series, then use the source .debs and recompile.

Has all this been done by someone and I'm just not seeing it? If not, does everyone else think it is a worth-while project? The intent would not be to get the various packages hildonized, but to get them to run in the nested environment so that the n800 can do double duty as a laptop replacement (when paired up with an external keyboard, mouse, and 16-gb memory card).

Re: Porting applicaoitns
 

I think yours is a very interesting idea, a fresh start, and I hope you'll go on when you get your tablet. If the Zaurus can do that, it should be possible here, too.

Re: Porting applicaoitns
 

Also, the virtual keyboard is not a 'standard' keyboard. It will not send keystrokes to normal X applications, only those who listen to them (like GTK widgets).

Re: Porting applicaoitns
 

This was the thought behind porting alternate window managers like KDE and others, you can then port without hildon changes, and mathbox limitations.

So if your using xnest/xepher (I am not familiar with either) is that addressed as a seperate display? This sounds interesting, but I wonder how fast it would be. It may be easy to run some small apps, but I fear running KDE and maemo at the sametime may be too much.

Currently KDE is able to be started from a menu icon, and gives full KDE with Koffice and printing, so isn't it already a laptop replacment? A bt mouse would be nice though!!

I for one am very interested in what you can come up with, and I look forward to it :D

Re: Porting applicaoitns
 

So that would then require some modifications to xnest to receive virtual keyboard input and deliver keystrokes to the child X server. Otherwise, a hardware keyboard should still work, shouldn't it? (bluetooth, USB, or the HW keyboard on the 810).

Xepher is what is used in the scratchbox dev kit. Xepher, xnest, xoo, these are apps that run under X, and create another sandboxed display (i.e., "localhost:2"). Any app that has it's DISPLAY variable set to that one will have it's X events sent to that sandbox, and they are then relayed to the parent X server. There isn't really any speed degradation that I'm aware of (not sure if any of the accellerated X stuff works though, like what mplayer or 3D games would use). The only performance related stuff would be the fact that there is more loaded in memory (the base Maemo matchbox window manager and background apps, in addition to what would be running pointing to the sandboxed environment). However if you are only actively working within one environment or the other, the inactive apps would end up residing in swap space, and not need to get swapped in that frequently.

Re: Porting applicaoitns
 

Good timing to request development ideas. This came out this morning:

http://tabletblog.com/2007/12/want-t...eres-your.html

Re: Porting applicaoitns
 

Do you have a tutorial on how to convert *.deb for arm architecture (like debian and ubuntu arm or armel packages) to armel for Maemo *.deb format?

That would be great if there is, or better yet, if there is a program to convert other debian arm/armel programs to maemo armel platform.

Re: Porting applicaoitns
 

There's no "convert" for that. You have to rebuild the program and create a deb. You can use the debian scripts for that. No guarantees it will build and run after that though.