Dear Roman, There exist two methods : listvar and listbricks used by the python interface which gives some information. But of course it is not But of course, this is not enough. Yes, of course, some methods can be added to the getfem::model object to extract information. I would prefer this option than expose references to var_description and brick_description objects because it is alway better to be the most possible independent of the implementation of an object.
Yves. On lundi 5 septembre 2011, Roman Putanowicz wrote: > Dear All, > > Recently I have started thinking about GUI components for GetFEM. > The aim of this GUI would be easier management of models, bricks, > etc. For instance I imagine a widget where I could see all bricks > added to a model and all variables associated with particular bricks > (sort of a tree view). > > I think that a central point of access to GetFEM data should be > getfem::model class. Given a reference to getfem::model object I should > be able to build graphical (GUI) representation of the model as well > as perform all sort of operations on it (like adding bricks, variables, > querying state, etc). > > Unfortunately getfem::model class shows some deficiencies from the > above point of view. For instance I haven't found an easy way of > querying how many bricks are added to a model (and I should know this > if I want correctly use a brick index). > This is easy to fix but there are other things related for instance > to model variables and their properties (scalar or not, FEM based or > not, etc.). > > Looking at the implementation of getfem::model one can see that most of > the information needed to conveniently build GUI for GetFEM based models > is stored in private structures: var_description and brick_description. > Unfortunately both are private ( I have found public declaration like > typedef var_description *pvariable; > but no way to get to var_description data). > The two main data members of interest 'variables' and 'bricks' are private. > > Now I have a couple of general questions: > 1) Has anyone attempted to build widgets for managing models bricks, etc.? > If yes what was your approach? > 2) What is better strategy for designing GetFEM model query interface: > a) add to getfem::model methods to extract atomic information about > bricks and variables > b) expose references to var_description and brick_description objects > (after turning the structures into classes and providing read > only interface to their data) ? > > With kind regards, > > Roman -- Yves Renard ([email protected]) tel : (33) 04.72.43.87.08 Pole de Mathematiques, INSA-Lyon fax : (33) 04.72.43.85.29 20, rue Albert Einstein 69621 Villeurbanne Cedex, FRANCE http://math.univ-lyon1.fr/~renard --------- _______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
