Do I really need *.nib files?
- Thread starter KBAKEP
- Start date
lurk
Mitä?
If you are not using nib files then you will never have awakeFromNib called so no problem. But since you are not using nib files you cannot use InterfaceBuilder to make your UI and you will need to create it all programmatically. That is a complex proposition. What you will need to do is figure out what objects you will need to realize your UI and then create them programmatically.
I don't have any real reference to this but you can look at a project called Renaissance from the GnuStep folks for some inspiration. Also GnuMail from the same source does not use NIBs so that my give you some inspiration.
-Eric
I don't have any real reference to this but you can look at a project called Renaissance from the GnuStep folks for some inspiration. Also GnuMail from the same source does not use NIBs so that my give you some inspiration.
-Eric
lurk
Mitä?
My question then is how do you intend to write an application with a GUI you could never debug? Aqua does not work over ssh. You may just be a better programmer than I but I usually need to run the application once before I ship it. 
If you have to work over ssh then your need to write an X11 application which you can tunnel over the ssh connection in which care you are in vanilla Unix land. The other option would be to arrange to run VNC on the mac to give you access to its desktop on your box. However if you do that then you can just use Interface builder and nibs.
I have a feeling that you have some conflicting requirements so what are you really trying to do?
-Eric
If you have to work over ssh then your need to write an X11 application which you can tunnel over the ssh connection in which care you are in vanilla Unix land. The other option would be to arrange to run VNC on the mac to give you access to its desktop on your box. However if you do that then you can just use Interface builder and nibs.
I have a feeling that you have some conflicting requirements so what are you really trying to do?
-Eric
symphonix
Scratch & Sniff Committee
You might also try writing your application in Swing-Java, if you know the language, that way you can write a single app that runs under Windows, Mac and Unix. You still have to create the interface programatically, though, but at least you can debug your code on a PC.
lurk
Of course I will run an app on Mac, but I can't do it anytime I need. So, actually I need to write an MacOS X GUI port of a quite large project.
To be more precise I can give you a link.
There I should to implement TVirtualX class and other GUI items.
I think that the first step is to write, for instance, CreateWindow class member.
Of course I will run an app on Mac, but I can't do it anytime I need. So, actually I need to write an MacOS X GUI port of a quite large project.
To be more precise I can give you a link.
There I should to implement TVirtualX class and other GUI items.
I think that the first step is to write, for instance, CreateWindow class member.
lurk
Mitä?
I checked out the application you are talking about porting. How many man years of work do you have to invest?
Honestly though that is an X11 application built on a custom widget set. Any effort to natively port the GUI would be a huge undertaking basically you will need to reimplement the whole thing along with its quirks.
In a manner of sorts I am a "rokit seyentist" and have been tracking several packages like the one your are trying to port to use at work. More often than not people have been deciding to stay with X11 as the basis of these applications and not go with an aqua interface. That makes perfect sense because it is really a significant jump to go from X11 to Aqua.
So the good news is that if you go the X11 route then all you have to do is port the code like it was any other Unix and you can do that without having access to the console via ssh. In this case OSX is just another Unix with a very good X11 implementation.
Do you have any objections to going this route? The xserver from Apple is really good and has support for OpenGL so your visualizations should be hardware accelerated for free (if they were under the other unicies).
I see that the program has been ported to linux, Solaris and HPUX. That gives you a good chance of having a fairly easy time of doing a port. HPUX gets you most of the BSDisms and the range of Linux offerings indicates that it is not doing anything too funky.
Was a "native aqua" interface given to you as a requirement? If you are being paid to do this to make someone else happy I can certainly give you help in that direction (cf. death march) but if you are actually interested in an effective solution I can help there too.
I honestly want to see as much scientific software for OSX as possible so please stick around and hash this out. I really want you to succeed and this is one of those areas that I get payed to work on so I really can be of assistance.
-Eric
Honestly though that is an X11 application built on a custom widget set. Any effort to natively port the GUI would be a huge undertaking basically you will need to reimplement the whole thing along with its quirks.
In a manner of sorts I am a "rokit seyentist" and have been tracking several packages like the one your are trying to port to use at work. More often than not people have been deciding to stay with X11 as the basis of these applications and not go with an aqua interface. That makes perfect sense because it is really a significant jump to go from X11 to Aqua.
So the good news is that if you go the X11 route then all you have to do is port the code like it was any other Unix and you can do that without having access to the console via ssh. In this case OSX is just another Unix with a very good X11 implementation.
Do you have any objections to going this route? The xserver from Apple is really good and has support for OpenGL so your visualizations should be hardware accelerated for free (if they were under the other unicies).
I see that the program has been ported to linux, Solaris and HPUX. That gives you a good chance of having a fairly easy time of doing a port. HPUX gets you most of the BSDisms and the range of Linux offerings indicates that it is not doing anything too funky.
Was a "native aqua" interface given to you as a requirement? If you are being paid to do this to make someone else happy I can certainly give you help in that direction (cf. death march) but if you are actually interested in an effective solution I can help there too.
I honestly want to see as much scientific software for OSX as possible so please stick around and hash this out. I really want you to succeed and this is one of those areas that I get payed to work on so I really can be of assistance.
-Eric
Actually I'm a scientist (high energy physics). I had a talk to developers. They said that native port would be very nice. But there is no one to do it.
First, that R. Brun said, was to rewrite TVirtualX class. I found out that it should be rewritten not only that class, but all GUI classes (like "native Windows port").
Unfortunately I haven't any Mac at home or at work. I plan to buy when possible (in Russia Macs are 30-40% more expensive, that , for example, at Apple Store).
But I can ask someone to help me in debugging it.
BTW, X11 port exists, but native one would be better.
The main thing I need is to start.
First, that R. Brun said, was to rewrite TVirtualX class. I found out that it should be rewritten not only that class, but all GUI classes (like "native Windows port").
Unfortunately I haven't any Mac at home or at work. I plan to buy when possible (in Russia Macs are 30-40% more expensive, that , for example, at Apple Store).
But I can ask someone to help me in debugging it.
BTW, X11 port exists, but native one would be better.
The main thing I need is to start.
lurk
Mitä?
I understand the desire to rewrite but to be honest unless you do it from the ground up the results won't be good. Just reimplementing all of the GUI classes will result in something which looks Aqua but won't behave correctly or be able to leverage the strengths of Apple's code. It will still just be an X application so just use X.
There is lots of pain and suffering down the road you are suggesting and unless someone is directly paying you to suffer like that I would not do it. You seriously are looking at something that will take at least 6-12 man months to do.
Also keep in mind that Apple's X11 implementation is getting really good. It has almost all of the benefits you would derive from reimplementing without totally redesigning the software.
-Eric
There is lots of pain and suffering down the road you are suggesting and unless someone is directly paying you to suffer like that I would not do it. You seriously are looking at something that will take at least 6-12 man months to do.
Also keep in mind that Apple's X11 implementation is getting really good. It has almost all of the benefits you would derive from reimplementing without totally redesigning the software.
-Eric
lurk
Mitä?
The problem is that GUIs and programming frameworks are like natural languages in that they have there own idioms, style, expressive strengths and deficiencies. A widget by widget port like you are talking about is in many ways analogous to a mechanical translation of natural language. A programming equivalent to the old urban legend translation of "The spirit is willing but the flesh is weak" to "The vodka is good but he meat is rotten" in some way correct but not really...
In order to support the assumptions the non-interface code makes about the way the interface works you will need to maintain the semantics at X windows. You will need to have a 3 button mouse or use lots of modifiers to simulate them. You won't be able to fully support drag and drop on the Mac because the existing code does not even consider such things possible. This is only the start of a list a mile long.
So I meant that even though you would have the shiny Mac interface it could not operate like a native application. It would only be a dressed up X11 application. As far as the Windows port goes I would suspect that is suffers from exactly these issues just in different ways because of the differing strengths of windows.
An important factor to keep in mind is that X-Windows on MS-Windows is not really a practical solution in that it is not free and easy. It can be done but there is some work and potential expense involved. (O.K. I haven't really looked at this option in 18 months so things may have changed but I doubt it.) So in many cases a clunky MSWindows port is the only option and to be honest with the number of really bad windows programs out there I think users may be conditioned to expect things to be kind of clunky.
With OSX we get X11 support basically in the box so to justify a native port one would need to do a true native implementation - one using native semantics - for there to be any real benefit.
-Eric
I'll just make some comments:
X-Windows on MS-Windows is not really a practical solution in that it is not free and easy
There's a native port for Windows (without any X-server).
About drag-n-drop: there's a plan to implement it in platform independed form (by XML).
So, the main "virtual" GUI code can be modified (how?) to make porting in easier way.
I'll ask in another manner: "Is it possible to make some changes to the main code? Will it be closer to MacOS X GUI?"
X-Windows on MS-Windows is not really a practical solution in that it is not free and easy
There's a native port for Windows (without any X-server).
About drag-n-drop: there's a plan to implement it in platform independed form (by XML).
So, the main "virtual" GUI code can be modified (how?) to make porting in easier way.
I'll ask in another manner: "Is it possible to make some changes to the main code? Will it be closer to MacOS X GUI?"
lurk
Mitä?
I think I misscommunicated something here. My point was that the port to Windows has to be native because using X11 in not a viable option there. The existence of a native Windows version only supports my argument.
That is easier said than done. The problem is that the different platforms have different ideas of what can be dragged and dropped and even what the result of that process is. In one case you really can only copy text, in the other data of multiple types and then finally whole external program components. Using XML as a representation will never be able to bring these things into parity. Rather it is a solution to allow manipulations internal to your program to work via the lowest common denominator method of simple text. This will not allow me to grab a graph and drop it into TextEdit.app and have a PDF representation inserted. I'll just get some XML stuff that cannot be interpreted.
The Virtual GUI code would have to be chucked since even the existence of such a beast does not bode well for real portability. What you need is an abstract model of the data and how it is manipulated. Then the different GUI front ends would need to be created to best provide the user access to that model.
As an example if you were looking at the action of deleting a file. On the mac you provide that functionality via a metaphor of dragging the file to the trash. There is no trash under X11 so you would provide a menu option or dialog box to accomplish the same task. Any virtual GUI assumptions about how this should be done would be wrong on one of the platforms and violate the expectations of the user.
Yes of course it would help to rewrite and restructure things to be more Mac friendly. But the important question is how hard would it be and what would one gain. My point is that it is hard to do the mechanical port and the results would be the same as just running it under X11 on the Mac. There is no gain there.
Now if you want to justify the port by doing a good job, something that takes advantage of all the goodness that is OSX, then that will be very very hard.
Portable software is a very tricky thing to write well when you are working with user interaction. The case where the GUI and the application have evolved together on one platform and then are to be ported is particularly difficult because there has usually been no effort to consider these facets of the application separately.
Really my point is that the current X11 solution we have right now is good. To go beyond that will require a significant amount of effort and be inherently non-portable back to the rest of the application.
This all comes back to my original question of why you wanted to do this. If you want to create a new OSX implementation to leverage the cool stuff in Cocoa then throw the old GUI away and start from first principles. If it is just to get Aqua buttons in the GUI then really it isn't worth the effort.
-Eric