Axis could be MUCH more than what it is, and maybe it would if the code base was more attractive. tk, the gui toolkit used is the single worst choice that you can make, and it's the main driver of the code's disorganization.
Refactoring axis to a better structured project that use the very best gui toolkit around (Qt4), you could get much more contributions. I appreciate the pointers you gave me (emcrsh, halrmt) but I do need high refresh rate for my experiments. I'll certainly begin by trying to mess around with axis code base, but, in the end it is not a very big program, and it may be simpler to simply rewrite it. For your <soapbox> comments, what you describe is a common mistake in software engineering. Any good software architecture separates the application logic and the UI, commonly known as Model-View-Controller architecture (see http://en.wikipedia.org/wiki/Multitier_architecture). A good "Model" here would expose its services to any kind of UI that you can think of. In our case, a big part of the model is the HAL, but you can have many sub-layers in your model, and the algorithmic/logic parts of axis should definitely be accessible outside the UI. So what you call a gui API, is in fact what AXIS model layer should be. On May 23, 2009 02:37:23 pm Eric H. Johnson wrote: > Maxime, > > Your willingness to contribute is certainly appreciated. My view is that a > new user interface needs a raison d'etre, where such things as simply > reorganizing the code or rewriting it in a modern gui environment would not > seem to meet that test. I can't speak for Axis on a coding level because I > have never bothered to learn Python, but regardless of the quality of the > code, it is by far the most popular user interface used with EMC. It would > also not seem to warrant a complete rewrite just to add a few more > features. > > OTOH, I can think of a few other types of user interfaces which certainly > could have a raison d'etre. One I would really like to see is a UI > specifically designed for a touch screen. In fact ideally having at least > two layouts. One for the 4x3 format and one for 16x9 format. > > If you want to write a UI in Java or other cross platform environment you > might want to consider using the emcrsh interface > (http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh) which uses plain text > commands over a simple socket (telnet) interface. For implementing stepconf > like or other "advanced" features, you might look into the halrmt interface > (http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Halrmt). This is a > complementary interface to emcrsh allowing you to issue any hal command > (except alias, which I have not gotten around to updating) over the same > type of socket interface. > > Obviously within the UI, password protection or similar technique can be > used to restrict access to these "dangerous" functions from the general > operator, while making them available to advanced users. > > The advantage of these interfaces (emcrsh, halrmt) is that the UI can be > run on almost any platform without having to setup a specific environment > like ssh / Xming, Python, Tk/Tcl, etc. This is certainly an advantage to > those wanting to have a Windows based UI. The UI also then becomes > independent of the specific version of EMC running as well. > > The downside is that it cannot maintain the update rate of a strictly local > user interface. The ability to display actual positions against programmed > positions at high resolution is a particularly powerful feature in Axis. > > <soap box mode > > Lastly, one area I have wanted addressed, but has pretty much gone over > like a lead balloon in the past, is adding a "universal user interface > API". By universal API, I mean adding a layer between EMC and the user > interfaces which both provides the functions typically needed by user > interfaces, while at the same type providing an interface which remains > consistent across versions of EMC. Ideally any UI should be able to be > compiled / interpreted separate from EMC and work with any version of EMC > having this interface. > > One thing I recently wanted to do was to implement a generic way of > applying a preprocessor when opening a g-code file. Axis has this feature, > but it is done within Axis. In my view, this should be a feature available > universally to any UI without having to re-implement it in every one. > > However, there is no point in pursing this unless the maintainers of the > existing UIs see sufficient advantage to warrant porting them over. > </soap box mode> > > Regards, > Eric > > > > I could argue that such a "casual user" could hurt himself in many ways, > and shouldn't be given access to the machine. > > > > > > > I'd rather postpone the stepconf discussion to later, it is not high > priority to me. Which brings us back to : > > > > > > > - AXIS code organization/refactoring > - opinion on the migration to a modern gui toolkit > > > > > > > or > > > > > > > Should I rather start a new gui project and leave axis as it is? Anyone > interested? > > > > > > --------------------------------------------------------------------------- >--- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is > a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
