SGI: Development

porting apps to Motif (help seeked) - Page 1

Hello,

first a short line of presentation: some people may know me under this nickname from the IRC channel.

My idea is to port some selected applications that have "alien" toolkits to Motif. Mainly I think from the "evil" gtk, especially gtk2. I find this idea interesting because

1. motif is fast and native, so it would improve speed in applications
2. motif is native on IRIX (and other unices, think solaris, AIX) and so a port would reduce dependence clutter (and system resource usage)
3. it would greatly improve the looks !
4. it would be not a wasted effort: other platforms may benefit, I always have lesstif or openmotif installed on a *BSD box or linux box. Thew are just faster than gtk (or QT)
5. it could potentially help getting new, useful applications on older platforms, like irix5 or irix4 where getting GTK to compile would be impossible

I myself can code C fairly decently, but UI coding is not my speciality, so I seek collaboration from others. People who know Motif and/or GTK are of course welcome, since they can help understanding what is currently done in the code and how it should be done!
If you feel busy, please, keep in touch anyway, I stress the point this is a spare-time effort and I will drop into the IRC channel and discuss matters and code from time to time. No time pressure of any kind, but the more we are the better it is.

Other reasons why this can be a good idea?
There are many applications written for GTK 1. Which was horrid but still usable. Now gtk2 is out (it has a MAZE of dependencies, runs as hell on older systems and fills up your HD) and many projects are eitehr trying to seek the switch or they are looking for alternatives. Motif is usually not considered, but in that moment some more clever authors decide to make the UI more independent or anyway remove some GTK trickery.

Although the target would be porting to current Motif 2.1, which would enable IndigoMagic and CDE users, it would be nice to keep it as 1.x compatible as possible, this could mean ported applicatins could run on older computers and on lesstif.
(think about the joy of having a new prorgam for your personal iris)

Besides porting new apps, we could also develop. If not from scratch, around the globe thre are scattered motif applications no longer maintained or for other reasons "bit rotting" we could try to revamp them.

I will start a thread for each application I find interesting. For now I have only one and let me collect ideas.

Thanks in advance for possible collaborations...
Don't want to start a flamewar because the decision which toolkit is suited best is highly emotional and personal, but I'd like to add a few cents, since I am developing software using qt for a few years now (exactly since the beginning of qt). I cannot comment anything about gtk, I never used and probably never will.

Before I started using Qt a collegue compared Qt against Motif. There have been a few issues which immediately showed up.

- Qt is much more natural to develop with ... you do not have to cope with lots of strings parameters. In fact you are much in the programming cycle. Developing faster means your time is spent on the problem and not in the implementation
- when using Qt source code tends to be much smaller and more easy to read for someone who hasn't seen this particular code
- I don't feel that Qt apps are much slower than using native gui code. In fact the part most speed in gui is lost is waiting for the user to do somethin. I write complex applications and the bottleneck is usually your graphics card or some expensive calculation.
- You get a very nice gui interface creation tool with Designer which lets a total newbie create a nice interface within minutes. Of course you are responsible to implement its connection to the application yourself. But this makes it possible that your customer can play around and give you a prototype how they like the application to look like.
- I don't like the Callback Stuff you have to use with motif. It isn't type safe and can lead to very subtle errors. Of course Qt forces you to use C++, which is not a problem in my opinion, but this is a very personal preference, YMMV.
-Porting back software from a "alien" toolkit how you call it, will take a lot of time ... if you have so much time it is ok ... but finding so much volunteers may be hard but impossible.

Of course I do not want to keep you from doing ... after all programming is about fun and you have to choice what to do with your time.

Matthias
Life is what happens while we are making other plans
Well I don't know if you already coded something that uses Motif widgets, but it's really shitty. GTK produces a better job (mmm, antialiased fonts, greater flexibility, it's free, etc.) and it's SO MUCH easier to develop with it!

Please note that I never coded anything with QT, but I'm sure it's at least as great as GTK.


Jason
I forgot one of the most important reasons why such ports are doomed to fail. Let us assume that you manage to port an application and it runs really well. Everytime the application gets updated with new UI or functionality you have to add those things again, and this will really be getting tough if you don't do it very often so those things might get out of sync very soon.

Matthias
Life is what happens while we are making other plans
I know it is not an easy task, but it is an interesting now. And yes, I coded some Motif, though never something really big.

GTK is crap, I don't care for 'eye candy" like antialiased fonts. Often I find them even disturbing. GTK looks ugly too.

Also while GTK 1.2 was reasonable, gtk 2.4 is totally out of control. I had absolutely no way to cram it and get it working on a sun ultra machine with solaris 2.6. And the hell of dependencies I had to compile and install wouldn't even fit on the disk I currently have on my SGI.

So instead of telling me GTK is better, I'd like to find people who could help me in the effort of accomplishing my task. If I had been happy with GTK I wouldn't have thought about this project, right ?

Another way would to try to revive aplications that existed for motif but that were abandoned, but this is I think more torublesome because of the bitrot...
My opinion: it's going to be a pretty hard task.

I know marginally GTK 1.x, I don't even consider GTK 2.x as it crawls on my R5K 200M O2, and when a GUI crawls on a 200 MHz processor just to pop up a menu, it means that is just a piece of stinking crap code.

Now, I have already seen this same movie in the Amiga camp, many many years ago. The lacking of a consistent, expandable toolkit led to the proliferation of 4 or 5 toolkits, each one of them of course claiming that they were the best. The net result, which is also something we are seeing today (partially alleviated by the usage of themes), is that you have a moltitude of applications, each one with its GUI and quirks, eventually mocked up to feel as much as possible as the original GUI.

The stupidity and blindness of OSF, with their nonsense licensing scheme for Motif, has forced the people to pursue a different path. I can understand their initial motivation: I would never stick with the poor Athena widgets. I understand much less what followed, i.e. the creation of a toolkit based on top of Xlib instead of Xt (GTK), with a complete different and incompatible API and programming model, plus the idea that the L&F of Windows was something to be pursued to make the applications more attractive to the Gates' users. It would have been much better if all the efforts were addressed to the finalization and enhancement of lesstif, creating a true competition (and with a better implementation) to the original OSF Motif.

Today, we have GTK 1, GTK 2, Qt, wxWindow, FLTK and Motif, plus eventually some more toolkits I'm not aware of. With the exception of FLTK, which is the lighter of them (but also not as complete as the remaining), the only snappy toolkit is Motif, which is native. Unfortunately, the real big problem here is that Motif is missing a lot of common widgets that you can find in almost every other GUI toolkit for any platform (unless, like some software house did, you develop your own private Motif widgets). And creating new widgets for Motif, if someone has had the time to skim over the Xt and Motif books, is not a trivial task, let alone the fact that Motif GUI builders tend to be commercial and expensive.

But even in the case of having an estabilished set of enhanced/added widgets for Motif, you are facing with the dilemma of who is going to use that enhanced toolkit. It's not that the mere existence of such a beast will make it automatically accepted in place of GTK/Qt/putyourfavoritenamehere. Which, in turn, means that the applications will still be developed with the "alien" toolkits, and you are forced to reapply a gigantic set of patches for every new version which will pop up. A nightmare...

There is one last thing to be considered: SGI specific stuff it's not something that all the Motif developers are aware of. When I made xmcd completely integrated with the SGI desktop, it tooks me more than a week of patches, and a lot of mail exchanges with the past SGI freeware coordinator, to achieve the result you have since a year. And xmcd is a Motif application, which in the past emulated the SGI L&F, but that in fact was not following the SGI reccomendations at all.

In conclusion, I think that a better way to spend your efforts would be to add the missing pieces to Motif (there are many, for example list trees), integrate them with the SGI L&F, dump all your enhancements on lesstif, and create of set of blazing fast applications that demonstrate how without using <yourmostdislikedtoolkithere> is much better. Of course, you will have to fight against the GNU/GPL talibans, against the "there is no life without a theme" fans, but so it's life... :D

Have fun,
AS
How about instead of rewriting the applications, rewrite the toolkit. Just use the same interface as GTK, but make it a wrapper around Motif. I'm sure this would be very difficult, but if done, it could make porting something to Motif as simple as relinking.
I'm not terribly familiar with either Motif or GTK, so I really have no idea how much effort this would require....

Personally, I think Motif and GTK are ugly (code-wise) and I don't like C++, so I stick with Xlib. Now, an Ada95 framework for X11 that was similar to Java Swing, that would be great!
Personally, I think Motif and GTK are ugly (code-wise) and I don't like C++, so I stick with Xlib. Now, an Ada95 framework for X11 that was similar to Java Swing, that would be great!


Well, Motif is C only (and afaik, gtk is C too) and you see most of the Xt underpinning motif and you use Xlib stuff to draw... so it is your choice.
Wouldn't it be more of an idea to create motif frontends for apps that have a frontend/backend spilt. That way you could have a Motif browser using Gecko but you wouldn't have to worry about changes made in firefox/mozilla/epiphany gui, same holds true for mplayer (there's the gmplayer frontend)
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better"
Sure creating a front-end for an application that already has a good splitting is better and easier.
But I didn't even specificed which applications!! I just suggested the idea and looked for helpers to join in the project and the discussion got in the detail already.

So these are my suggestions

-Browsers:
1. Dillo
Dillo is fast, clean and very nice. It will never compete with mozilla or konqueror, but that is its strength.
Currently it has been proven quite portable and it is written in GTK1. The team decides to go over to FLTK probably amd during this process the abstraction of view and engine (already present) ill be improved. It is the best time right now to underline the good idea behind this division.
2. Updating and improving an existing browser like Arena or mMosaic
3. Writing a new gecko based browser native on Motif. Like galeon is for GTK/Gnome. I think that would be nice, but a lot of work that maybe would never be finished.
4. writing a motif port for the links browser graphic part.

Personally I prefer idea 1. it would rock even on older computers and it seems that the maintainers of the project are "open" to portability issues and like quality code.
Links code is spaghett. My old compiler from SGI on irix 4.0 just doesn't like it... I fixed 80% of the stuff to get the text-only version but for now no results.


The I'd think a X-Chat port to Motif would be nice too.

And a Motif version of "gaim" or "Ayttm". That could be a rewrite from scratch using the same libraries those programs use.


That is the first bunch of ideas. Porting my image filtering program to IRIX would be nice too, but it is quite tied at the moment to the Objetive-C/OpenStep architecture.

if others hav ideas or proposals join in. Although starting the dilo port asap would be good to show the interest to the dillod evel. before it is too late.
gandalf wrote: That is the first bunch of ideas. Porting my image filtering program to IRIX would be nice too, but it is quite tied at the moment to the Objetive-C/OpenStep architecture.


I just don't like Motif that much, so excuse me if I don't leap forward to work on this project.

Anyway, in what ways is your image filtering stuff tied? I believe that GCC's Objective C support works fine on Irix. So, if you were to port the GNUstep backend over you would probably only have to redo any GUI code to use Motif instead of the NextStep GUI libraries.

As to your project in general, what's wrong with FLTK? Being based somewhat on FORMS, to my understanding, it seems that using FLTK on Irix is about as true to the spirit of SGI's heyday as Motif is.

I also wonder about the posibility of going back and using FORMS. It is based on IrisGL, which I find particularly appealing.

Recently, I've been having a strong desire to go back to a Crimson like machine, or early Onyx, running 4.0.5 or 5.3, and writing IrisGL code for my projects instead of OpenGL/SDL/FLTK code (don't ask why I'm bothering to use SDL. It has to do with not yet figuring out how to do everything in FLTK).
FORMS is the toolkit with which Jot, showcase and other programs are written? I like its menus (in the 6.5 version at least, the 4.0 they are a bit crude) and the design of the widgets. But SGI itself touts it as "obsolete toolkit". I never programmed it. Also I don't think it is cross-platform.

The advantage of Motif is that it would work smoothly on other Unices too and even on *BSD or Linux with OpenMotif or even better Lessitf.
gandalf wrote: FORMS is the toolkit with which Jot, showcase and other programs are written? I like its menus (in the 6.5 version at least, the 4.0 they are a bit crude) and the design of the widgets. But SGI itself touts it as "obsolete toolkit". I never programmed it. Also I don't think it is cross-platform.

The advantage of Motif is that it would work smoothly on other Unices too and even on *BSD or Linux with OpenMotif or even better Lessitf.


After mouthing off about FORMS, I figured I better go look up some information about it. I already knew it was based on IrisGL, and as such was somewhat of a dead end. I always figured that Jot and Showcase were now motif apps. I believe that Showcase was formerly forms based though.

Anyway, if one wants to write software that will run on Onyx4s, FORMS is certainly not the way to go. However, there is also XFORMS. It is like FORMS (I think it is partially compatible, but I'm not sure), but it uses X11. Where FORMS would let you drop down to writing native IrisGL code, XFORMS lets you drop down to X11 or OpenGL.

Both FORMS and XFORMS have the source available. FORMS may be a bit of a dead end because of it's dependence on IrisGL, but XFORMS has no such limitation, and should work on everything from MacOS X to Linux.

Now, what I would like to see is people really writing software for older SGIs. Some porting is allowed and encouraged (why use old jpeg and tiff libraries?), but I'd like to see stuff written to run on Irix 4 (and later) and using IrisGL instead of X11/OpenGL. Yes, call me crazy, but that's what I want. Of course, I'm not exactly backing it up with actions. For one thing, nothing I have is running anything older than 6.5.20 yet.

I also wish that more old software could be found. Like, Flame 3.9.10 comes to mind as something that would be very nice to have (I think that was the last IrisGL version, and I think it would run on a Crimson VGXT with Wacom tablet). Software from Alias and Wavefront prior to the merger would also be extremely cool.

Alas, when I have seen old stuff, I haven't been able to afford to buy it (I say a flame 4 on Onyx once, but it still went for over 15 grand).
hmm, I'd like too some software on my personal iris. However if not for some personal satisfaction... writing pure IrisGL is crazyness.
Also mind I don't know *GL but I always wanted to learn.

I have seen some motif+irisGL demos that are exceedingly nice. Writing an application that runs both in irisGL and openGL would be cool.

When I could compile Xftp on my personal iris I was somehow happy. Motif. and it runs fine :)

Also I can assure you that the showcase 3.4 that I have (a wonderful piece of SW, btw) is not motif based.

If you have old source code around we could try to compile it and if the license permits it revive it.
http://world.std.com/~xforms/

I found xforms here, but the stuff seems me little updated and also. And I found no references to the SGI toolkit and the compatibility. I wonder also if sgi provides libraries for it in irix4 and irix 6.5 ... look if you fid something suitable in /usr/include I found the runtimes in /usr/lib but they may be for compatibility only

(the excellent imageworks is forms based too)
gandalf wrote: http://world.std.com/~xforms/

I found xforms here, but the stuff seems me little updated and also. And I found no references to the SGI toolkit and the compatibility. I wonder also if sgi provides libraries for it in irix4 and irix 6.5 ... look if you fid something suitable in /usr/include I found the runtimes in /usr/lib but they may be for compatibility only

(the excellent imageworks is forms based too)


How often a thing is updated is only relevent if it lacks features that you are hoping someone else will add for you. If it does what you need, who cares if it gets updated?

As to compatibility, I think it comes in the form of the API being similar, and being able to load FORMS layout files. XForms isn't SGI specific (unlike FORMS, which was pretty much SGI specific, although I heard rumors of a AIX port), but I know people used it. But, that doesn't mean that SGI ever used it internally (which I think that did do with the original FORMS). Still, if you can still compile it, again, who cares how much SGI did with it.
How aoubt X-DESIGNER 7?

http://www.ist.co.uk/xd/

and ICS QT and BXPro

http://www.ics.com/?cont=nix
I've never used BXPro, but X-Designer is a very slick application! Designing, simulating, compiling, and testing a GUI was very fast and very easy on an R12K/400 O2 running X-Designer 6.0.

But it's sooo expensive. You might be better off with an O2 running 6.3 and RapidApp. (This is the combo Cesar used to help him write Pegamento).
It should be possible, and would probably be a whole lot faster, to build a shim library for GTK and Qt, that looks like the actual GTK/2 and Qt libraries, but is really just a wrapper to Motif. It would certainly be faster than trying to rewrite all the apps.
There's an old proverb that says pretty much anything you want it to.
:O2: <-> :1600SW: eidyia - R5K/300, 1GB, AV2
:O200: Unnamed - 2xR10K/180 1MB, 256MB
Yes, some sort of "wrapper". It wouldn't mabe obtain the maximum performance of a native application, but would ease porting (and keeping in sync) a lot. But an intimate knowledge of QT or GTK is required, so I myself don't apply!
But if someone join sin I could try to help anyway and learn from both worlds.