Hi guys,

I've seen several posts where people wanted to run their QTOPIA apps on X, or pure QT but couldn't because of dependencies on libsl or other proprietary sharp libraries where source is unavailable.

Can anyone either give tips/tricks on how to port these specific library calls to QT/X11 libraries, or can someone point me to a good thread/forum/resource that would give me a good starting point?

The application I'd try to work on first is FreenoteQT, which I love. I haven't contacted the author yet, because I don't know what I'm looking for in the source code yet. Your help is appreciated.

-Daniel

Instead of porting these libraries to QT/X11, what about cross-compiling the Qtopia Virtual Frambuffer? I think the source is in the Qtopia-free SDK src RPM, so you should be able to cross compile it for the PDAXROM.

Then just make sure the Qtopia app can see all its dependent libraries on your Zaurus and run it on its own in the Virtual Framebuffer. Don't know what performance would be like though, but it isn't emulating much AFAIK.

Tumnus,

Thanks for the interesting idea! I was thinking more along the lines of changing the sharp code to QT code, or similar. Have you run anything in VFB on your z?

Anyone care to share any experiences moving libsl code to QT/X11?

-Daniel

Try taking a look at Opie's implementation/emulation of the libsl classes (opie/libslcompat).

- ashikase
anpachi, gifu, japan

Unfortunately, Opie's libslcompat is more or less pointless. I started it to get one of the japanese apps running, but the effort was more or less wasted, since it would take months to do a full compat library. Maybe a coordinated activity could get it going? Patches (as always) welcome.

Oh btw., I don't think the qvfb approach is sensible. qvfb is slow as molasses even on a fast x86 pc. i really don't want to see how it performs on a Zaurus

Mickeyl:

Does the SlFileDialog implementation work?

If not, my app isn't going to work for OZ people (^_^)

- ashikase
anpachi, gifu, japan

Can't remember that, but probably not. libslcompat was started as a class library with empty methods to get things compiled. Functionality was the 2nd step, which was never completed.

Let's do it. Should we split up the most important pieces amongst those who are interested? How long would it take with 3 or more people working on this in their spare time?

-Daniel