hi, On Tuesday 23 March 2010 15:42:24 Alan Grimes wrote: > Julian Bäume wrote: > > I don't see an easy way to change this, without bringing back the "one > > class for each component" problem, which IMHO doesn't scale. > Yes, > But, > we are only trying to *PORT* ktechlab right now. Well, "porting" the GUI means rewriting it. At least in our case. Since the QCanvas things are so tightly coupled to our Components and everything, this will also effect some parts that _should_ be quite easy to port..
> Moving to loadable components at this juncture goes into Deep Design > Decisions which I want to have a say in. =\ > And because I don't have the tools to work on the new version right now, that issue should be fixed.. but you must set-up these tools. the wiki describes some details you have to take into account, but basically it is possible to make it work ;) (for me it was just installing a recent version of KDevelop including the kdevplatform-devel files. After that, it's only fine- tuning... > I am really dismayed that changes are being made that will be difficult > to revert in the future because I want to take it in a different direction. I don't think most of the decisions I made are hard to revert. I haven't written too much code, I think. I checked for possibilities and reverted quite a few things, I tested and found that they wouldn't work very good for us. > Elsewhere in your post, you described the plugin loader as working by > "magic". This is unacceptable. If it isn't documented well enough to be > well understood, then it should be ignored. Well, I understand the technology behind all this. I called it "magic", because IMHO it's not an easy task to provide a nice infrastructure for a plugin-system, that is portable to many platforms. All this is provided by the KDE framework and therefore I use it.. and really like to use it. Qt itself is quite advanced with handling plugins, but the KDE Plugin-system makes it even more easy to use. You can have type-safe Plugins without dynamic casts and the way you describe the Plugins is really beautiful. Mostly all this is a collection of macros (providing an easy way to create factory classes that will create instances of your plugin) and the c++ template system to provide compile-time casting of your plugins. KDE will also provide better features to ship new plugins as 3rd party modules than Qt does, so I think, we really should stick to the KDE infrastructure here. > Consider, we have a new volunteer (or even myself), how do we bring that > new person up to speed on the project if they (or me), can't understand > how it's actually working? I think, I have a quite good understanding of the KDE infrastructure and it technology. If anything is unclear, just ask and we will figure it out. > My own solution to the scaling problem is to provide a user editor and > viewer for components that will allow you to inspect and edit the model > for that component. This would work with .component files or something > that would be viewable and editable (to some degree) in something like > kxmleditor. That's exactly what I had in mind... Not really with XML, but an easy way to provide the equations from external sources and not hard-coded into many, many cpp files, as it is done right now. Using Qt and KDE technology will really help us, here. You wanted to do that after the port. This should be okay, if we just strip every GUI related stuff out of the ECNode classes. After that, they should be really easy to port. > Once again, these changes are for versions AFTER the port is stabilized. I agree. As I said. Porting the GUI means rewriting it. well, that's enough from me, for now ;) bye then julian ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
