PDA

View Full Version : LW & the Hub, and a solution?



Captain Obvious
03-05-2005, 07:34 AM
From what I've gathered, many of the problems in LW for Mac comes from bugs and other issues with the Hub. It'd be very nice if a developer of LW looked into THIS (http://www.linkbackproject.org/about). I don't know if it is even possible at all, but I figured it was worth posting.

eblu
03-08-2005, 11:25 AM
is it possible? yes. would it address the issues with the hub? no.

link back is an encapsulation technology. it harkens back to the days of opendoc, and the weird, homogenous document strategy that was the focus of OpenDoc. the idea is that you make a generic file and add specific data to it. The document and the application handling the document, doesn't know or care what its contents are, the contents are handled by other applications. it was intended for multimedia, such as presentations, web pages, email, anything that needed to contain data and objects that were not like each other. it was light years ahead of competing technologies (PDF was the closest technology, and it STILL doesn't do what openDoc was capable of back when it was introduced)
linkback lets you take your graph, quicktime movie, whatever... and put it inside of another file, that doesn't know, care or interact with its encapsulated contents.
ie: that graph is still drawn/rendered/supported by the application it was made in (even if you make changes), but it lives inside a document of another application.
this isn't what Layout does. Layout knows, understands and supports all of the file formats it can open. It has to, bc OpenGl does not tolerate unsupported data, and the renderer, is probably just as picky.


the Hub is a messenger, it carries data back and forth between modeler and layout.

applying linkback concepts to lightwave, would be like fixing the problem by killing the patient.

there are better ways to fix the hub, however. the first step would be to simplify. The hub is an extraneous application, all of its functions can be handled much better by its charges, namely layout and modeler. everyone has played telephone in kindergarten right? that game where you whisper the phrase into the ear of the guy next to you... and then at the end its wildly distorted from the original. well, the hub is a source of distortion, one of those kids in the middle of the chain, that doesn't start out with the information or need to act on it. its better to just simplify the chain, so that theres much less chance of screwing up the information (or crashing).

every modern OS that runs Lightwave, has easy to use, and robust inter-application messaging options. Some have quite a few. the lightwave team needs to pick one for each os, and stop trying to re-invent the wheel.

Captain Obvious
03-08-2005, 03:51 PM
Ahh... Well, I guess that wouldn't really work, then. Still, LinkBack is a nice concept.

pantone
03-09-2005, 08:01 AM
I'm curious what's up with the HUB on Mac. I purchased LW at 6/6.5 when the HUB was new and I would constantly get crashes when I quit the application.

I skipped the 7.x versions for other software and came back with the 8.x version...and still I get the crash of Layout or Modeler on quit.

I've searched through these forums and seen a few posts about it, but no explanation of why it's happening or why they can't seem to fix it.

When I quit I can always tell when it's going to crash because I can hear my hard drive furiously writing...then "poof".

toma
03-09-2005, 08:21 AM
I don't have a clue of what's going on with the hub, but any scene with more than a few simple objects will crash layout or modeler when the hub is active…

very sad, because with PCs there is no problem…

I like the idea of the modeler beeing separate from the layout, but on a mac it's really a pain to manually save from modeler, replace in layout, load the missing layers if the object has new layers and so on…

thomas

eblu
03-09-2005, 02:57 PM
I think the hub is "as good as it is going to get."
it was designed to force an understanding between two applications that for technical, legacy, and legal reasons, could not interact on a more intimate level.
The mac hub, has always had problems that made it go cross eyed from time to time.
I don't use it.

the hub retains its own versions of objects in layout and modeler, but lets both applications work with them. thus any changes to an object in one, is applied to the other. this creates a virtual "clipboard" that only works with layout and modeler, and facilitates a message system to and from each application, so that the hub can alert them to changes or become alerted itself.

this is fundamentally more complex than it needs to be. while I won't say that complex is bad, I myself don't believe in doing more work than is necessary. in software, it not only takes more effort, it also leaves room for more bugs, and more flaws.

the simple way to do it, is to allow both apps to work the way they always did (before the hub), but if both apps are running concurrently, then layout should offer itself as a slave to the internal data that modeler has. If layout has a file that modeler has open, then it uses the data modeler has, otherwise it doesn't worry about it.

This lets us rely on decades of fine tuning, using the internal data structure, instead of a superflous copy, avoiding doing double work, and avoiding introducing bugs with brand spanking new software that are already squashed in the mature and tested heart of modeler.

doing it this way eliminates the confusion of... "which object should I save to keep the changes I made?" when the hub loses connection to modeler and layout. you save your objects in modeler.

another necessary benefit, is the leverage of the tools available. the hub does its own messaging, and it sometimes doesn't work, its flakey, and a source of problems. Each platform (windows Mac osX Linux even) has its own robust interapplication messaging systems, some... like os X have Several messaging systems, and each and every one of them are used by countless developers, more suited to fix potential problems, and drive the quality of the software up. By using these off the shelf tools that are specific, tested, and widely used, a software engineer can be assured that he writes Less code, introduces less bugs, and that someone else is always making that bit of software better, for free.

under osx, there are quite a few options when it comes to interapplication messaging.
applescript is very capable of this, and even though it is a "high" level app, it can easily be setup to do some slick things, like: talk to applications running on other machines, through IP.

it takes a little bit of research, and a little bit of work, but relying on proven tools, whether platform dependent or not, is much safer, better supported, and less likely to crash than reinventing the wheel.