New screen shots of myPDA-Zaurus-Edition

[dhns]

I have installed new screen shots of myPDA-Zaurus-Edition DR3 at

http://www.dsitri.de/wiki.php?page=Screenshots

so that you can get a first impression what is already working on this release.

We know that there are still some glitches in the visual appearance and the icons are rather old-fashioned (they originate in the old GNUstep base), but we are constantly working on improving that. If you want to help (design, debugging etc.), please contact the development team by PM.

-- hns

[Ovi]

Hi
Unfortunately my Zaurus (SLA-300) is not supported, otherwise I would happily try your software. Anyway, I had a look at your latest screenshots and I notticed that  the soft improuved as compared with what I was able to see from previous screenshots. However I have to make some remarks/suggestions:
1. I think your package addresses more the Mac users who would like to have a PDA with the same look/functionality/simplicity/abbility the port applications with their computer. Therefore yoou should pay more attention also to the way your system looks. For example the icons are awfull, you should contact a icon designer or something like this (may be some guy from IconFcatory) to design some modern/photorealistic (may be) icons for your system to make it more appealing. The normal user of a zaurus is I think a linux geek and you will need something more appealing to move him from his trusted qt enviroment to a STEP/Cocoa/Objective-C one. Also the window decorations I think are too big, taking to much screen space. Also here, may be you will drope the "golden delicious" as your symbol and use something else (not to get in trouble with apple when the your product will reach the "critical mass" for selling). Instead you can use something as simple (a leaf, sakura, etc.), but stilized. Unfortunately I have no programming/artistic talents, otherwise I woul have helped you here.
2. When the product is mature enough, I think it should be made available as a ROM update/upgrade/installation, but keeping the possibility to install/run the usual qt-based software available for  zaurus.
3. How are the syncing possibilities with the mac/linux/windows based PIM applications?
Well that will be all then. When at least 1 and 2 are fulfilled then I'll buy from you a new zaurus with the new system installed on it.
ovi

[Mickeyl]

Dr. Schaller, out of curiosity - how are you building the binaries for your distribution?

If you do it standalone you may want to look into the OpenEmbedded build system and metadata. We are always open for new GUI environments. By using OpenEmbedded, you could rely on a system designed for cross compiled and featuring metadata for over thousand packages.

[dhns]

how are you building the binaries for your distribution?

If you do it standalone you may want to look into the OpenEmbedded build system and metadata. We are always open for new GUI environments. By using OpenEmbedded, you could rely on a system designed for cross compiled and featuring metadata for over thousand packages.

Everything is currently built on MacOS X using Xcode and Zaurus-X-gcc 2.95.3. The installer files are generated by special makefiles and shell scripts with the proper cp, mv, ln, tar, gzip commands.

They generate finally two files for the installing the full package on a Zaurus:

1. a simple .ipk that installs noting but runs preinst and postinst scripts which
load the second file
2. a second tgz file containing the data files

The reason for that trick is that the preinst script can unzip and unpack the files on-thy-fly while ipkg install unpacks to /tmp and then copies. As we currently fill approx. 70% of the local memory of an otherwise naked Sharp ROM 3.10 the ipkg is not capable of installing the package or handling a feed.

The final installation of user applications (e.g. from independent developers) is planned to either work similar as the MacOS X .pkg installer or can be done by simply copying/moving .app bundles. Those can be packed as .tgz (for Mac users: sorry, we can't load .dmg images as there is no public specification out there).

So, users can download a .tgz by any means from any source, then click once or twice on the downloaded package and end up with a running application.

-- hns

[dhns]

Many thanks for the recommendations!

Unfortunately my Zaurus (SLA-300) is not supported, otherwise I would happily try your software.

What we really require is a ROM 3.10 (I think ROM 1.20 for the C7xx series is the same) and enough free memory space. For example a SL5500G is filled from approx. 25% to 80% meaning we need enough space to install about 20MBytes.

1. I think your package addresses more the Mac users who would like to have a PDA with the same look/functionality/simplicity/abbility the port applications with their computer. Therefore yoou should pay more attention also to the way your system looks.

Exactly. We have paid first attention to make the system running and implement some basic features so that we can start to work on the real look&feel.

For example the icons are awfull, you should contact a icon designer or something like this (may be some guy from IconFcatory) to design some modern/photorealistic (may be) icons for your system to make it more appealing.

100% agree. We will pay more attention on this from now on.

Also the window decorations I think are too big, taking to much screen space. Also here, may be you will drope

We have taken a not so recent Window Manager (mlvwm) which simply pastes MacOS 8/9 like decorations.

2. When the product is mature enough, I think it should be made available as a ROM update/upgrade/installation, but keeping the possibility to install/run the usual qt-based software available for zaurus.

This would release some of the memory burden although it makes installation more difficult.

3. How are the syncing possibilities with the mac/linux/windows based PIM applications?

We are working on modifying ZMacSync to handle the myPDA system as well. It is a little simpler as we do not have to translate the PIM database formats back and forth. I can't promise when, but it is definitely on the agenda for the next release.

-- hns

[orca]

We have taken a not so recent Window Manager (mlvwm) which simply pastes MacOS 8/9 like decorations.

Is there a particular reason that the Classic interface is used rather than a more Aqua like interface? File navigation, for example, seems out of place when using the MacOS 7-style windows. Would it just be a matter of adding updated graphics to mlvwm? The current combination strikes me as an uncomfortable constract between old and new user experiences.

Of course, I'm still trying to get me hands on a Zaurus so I can play around with myStep on something other than my PowerBook.

[dhns]

Is there a particular reason that the Classic interface is used rather than a more Aqua like interface? File navigation, for example, seems out of place when using the MacOS 7-style windows. Would it just be a matter of adding updated graphics to mlvwm? The current combination strikes me as an uncomfortable constract between old and new user experiences.

The original decision (one year ago) was based just on the fact that mlvwm was available and compiled immediately without any flaws and allowed to get first user experience. But it uses Classic style.

We are currently evaluating to either
1. use InterfaceWM (from the GNUstep project) - but it is more NextSTEP style
2. integrate basic Window Manager stubs into mySTEP and have our own WM

Changeing mlvwm is not a real option, as it is too different in internal code structure. We currently prefer to try option 2 as it would allow to use e.g. NSColor and NSImage in the window manager itself. So we do not have to care about harmonizing two different parts of the user experience.

-- hns

[Ovi]

Under which license will the future integrated windowmanager released?
Will it be GPL?

[dhns]

Under which license will the future integrated windowmanager released?
Will it be GPL?

- InterfaceWM is LGPL
- mySTEP is LGPL

so it will be LGPL either way...

-- hns

[charlesa]

We are currently evaluating to either
1. use InterfaceWM (from the GNUstep project) - but it is more NextSTEP style
2. integrate basic Window Manager stubs into mySTEP and have our own WM

Yes please on the NeXTSTEP/OpenSTEP GUI - NeXTSTEP style is not only ok but preferred!  Aqua is very, very good, but the NeXT GUI still is the best out there.  Sure the same team evolved Aqua from the NeXT GUI, but they had to accomodate Mac users.  

But I may be in a minority, and Ovi's metapoint is right:  to get mySTEP to appeal to current/future OS X users, the UI needs to be as Aqua-like as possible.

(showing where my loyalties lay - I still have two NeXT slabs, 2 Object.stations and a OS X Powerbook)