Re: Devices for embedded GNUstep development

[address@hidden]

> > I think the main problem for the GNUstep developers is to have a
> > common handheld device platform to develop for. I know some of you
> > have a N770 or N800, some others have a Sharp Zuarus. But I don't know
> > of anyone to own a Neo 1973 (besides me).
>
> I would say the biggest problem is the difficulty of getting GNUstep  
> to work on these devices.  I own a Nokia 770, and have never done any  
> development work on it because I was so frustrated with the cross-
> build environment that I gave up on it shortly after finally  
> persuading it to install.  I'm quite happy to have a toolchain  
> installed on the device to

I also have a N770 but it was the most difficult one to develop for -
so it is still
sitting around. The scratchbox thing is useless if you are developing
on a Mac.
So I used my standard gcc-arm-oabi toolchain. But then you don't have
the
automatic support for header files, packaging etc.

The next thing is that there is no recent update for the N770. Only
the 800 and 810.
And, they have switched to EABI - for which I don't have a working
compiler.

> GNUstep and the ARM cross-compiler toolchain[2] or a native build  
> environment for the device that I can access via SSH (I tend to do  
> most of my development via SSH anyway, so having the remote end being  
> a palmtop really makes no difference to me).

Yes, that is what I use for years for the Zaurus, the Acer n30/Letux I
have mentioned
and now even for the Openmoko Neo 1973. Run a Xtoolchain on the Mac
and deploy
the files through ssh to the device.

Yes, the display is QCGA - but that is no problem with AppKit
resolution independence.
And, the Acer is a device where it is known to work with ARM-OABI...

> While I'm not hugely interested in the hardware, I would be very  
> interested in working with anyone interested in mobile GNUstep and  
> especially with mobile Étoilé - I think CoreObject and EtoileUI will  
> make a lot of sense in a mobile environment.
>
> In particular, I would be interested in defining a set of defaults and  
> behaviours for small-screen devices where things like overlapping  
> windows don't make so much sense and floating palettes want to be  
> hidden most of the time.

I think we should simply discuss the ideas that are already
implemented in mySTEP and
maybe Etoile could use some of them. My results show that most UI
elements
of AppKit can be used/transformed in a very straightforward way by
adding
some glue code or simply doing the right settings in GORM/IB.

Example:
* mobile device has small portrait screen 320x240
* desktop has landscape and large screen
* App assumes a window in 600x400
* if window is resizable, force it to to shrink when loading from NIB
* if window is smaller and resizable, enlarge to full screen

Then, all application windows (e.g. NSDocuments) will automatically
become a stack. And through the Windows menu, a user can
reshuffle the stack.

The App doesn't even have to change anything. If it is compiled
on a desktop it just works as a desktop app.

Save Panel, Color Panel, Font Panel are just panels that open as
modal panels as usual.

The only concept that does not properly fit are NSDrawers and
application generated floating palettes.

It should even be possible to mimick the window sliding of the iPhone
GUI
by redefining how orderFront: and orderBack: works. If these methods
additionally slide the new window in from the right side
(NSAnimation...),
the window stack behaves quite similar to the iPhone.

I would be very interested to add the N770 (again) to the list of the
devices
supported by mySTEP, so we should exchange status and ideas on that
device.

BR,
Nikolaus