From nitro at dr-code.org Thu Aug 4 09:22:37 2005 From: nitro at dr-code.org (Nitro) Date: Thu Aug 4 08:51:01 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050726171057269.RTBD.6259.t-mta8.odn.ne.jp@mta8.odn.ne.jp> References: <20050726171057269.RTBD.6259.t-mta8.odn.ne.jp@mta8.odn.ne.jp> Message-ID: Am Wed, 27 Jul 2005 02:02:52 +0900 hat Koichi Tamura geschrieben: > What do you think about sth like this? > (Note I didn't give a careful consideration to it so it may > contain fatal mistakes) > http://hohehohe2.hp.infoseek.co.jp/kerama/GUI1.jpg > http://hohehohe2.hp.infoseek.co.jp/kerama/GUI2.jpg > > I haven't taken into consideration about... > > - Where to write WindowShape and any wxPython related code > - Custom shape, property editor > - ... (a lot more) > > Koichi To me this looks very good! From nitro at dr-code.org Thu Aug 4 09:35:55 2005 From: nitro at dr-code.org (Nitro) Date: Thu Aug 4 09:04:19 2005 Subject: [pangalactic-dev] Kerama core classes In-Reply-To: <20050730155345530.KQWN.6259.t-mta8.odn.ne.jp@mta8.odn.ne.jp> References: <20050725183627226.LYZG.6259.t-mta8.odn.ne.jp@mta8.odn.ne.jp> <20050730155345530.KQWN.6259.t-mta8.odn.ne.jp@mta8.odn.ne.jp> Message-ID: Am Sun, 31 Jul 2005 00:45:38 +0900 hat Koichi Tamura geschrieben: > Hi, > > One reason I don't like a typed property is, it pushes a kind of > restriction > to programmers. I really like Python (or smalltalk, ...) like non-typed > variables. It's very programmer friendly. It should be applied to Kerama > too. > For example, say we have a node that has property a and b and outputs > their sum > to property c, we can simply write a function: > > calc.c = self.a + self.b > > here the value of a and b can be either numbers or strings. In another > case, you > can write a function: > > calc.c = (self.a, self.b) > > then property c will be the tuple of a and b. This node can be used for > all the > types. > > One approach to have a nice GUI for properties is that we make both > typed and > non-typed property (like Visual Basic). > Another approach is, we give information about an appropriate property > edit > dialog to the property. > The main difference is, if we want the type information to be used when > we > connect properties, or only when the property is edited manually. I agree with you about the beauty of untyped languages and I prefer to use them, too. My main use for types is to determine which property editor to use. There could be different editors for the same type. A date property could be edited with a calendar control or by entering the date as a string. Of course you don't need to base this on types. You could aswell put a member called editors into the property which is a list of the possible editors. Maybe we should decouple editors and coercion though. There should be objects which can "cast" different strings (like DD/MM/YY or DD-MM-YYYY HH-MM) into a date. The editors could then be made fairly generic. For example you could use the same string editor for entering integers, floats, strings or dates. You would just use those "casting" objects to convert the output of the editor into a suitable property value. The "casting" objects are what is called types in wxOO. So a date type can cast strings or numbers into a date value. DO you think we should use wxOO instead of building our own system for editing? This would save us a lot of work and we get a good framework for editing. I tried it for my application and it works very nicely. > In either case, the information can be stored in another property. and > GUI can > be put as a plug-in or something. > > > Koichi -Matthias From kotamura at wood.odn.ne.jp Thu Aug 4 21:28:17 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Thu Aug 4 21:36:37 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: References: Message-ID: <20050805013633187.KWY.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > > What do you think about sth like this? > > (Note I didn't give a careful consideration to it so it may > > contain fatal mistakes) > > http://hohehohe2.hp.infoseek.co.jp/kerama/GUI1.jpg > > http://hohehohe2.hp.infoseek.co.jp/kerama/GUI2.jpg > To me this looks very good! Thanks! We need to hear what Steve thinks. It's natual he may have a different idea since the GUI is somewhat Kerama centric design. I have a very abstruct picture of Pan Galactic GUI (Model, Document,... are colored differently, and there could be a filter to limit the type/number of nodes shown in the diagram...) but the image I have is very very opaque. Oh, he may think it's still not a right time to think about GUI design :). I updated my idea to see how you guys think about application interfaces with which GUI can communicate with the application. > property editor and wxOO Sound's interesting, but I need more information around them. I'll check out wxOO and BasicProperty closely. I've updated "Kerama specification draft 0.8 (under construction)" It's a draft, it's 0.8, and it's under construction. heh http://hohehohe2.hp.infoseek.co.jp/kerama/spec/draft0.8.html (It is not a GUI spec. If you see 'property editor', replace it 'something which can be represented by "property editor" ') Basically same as what we've discussed here, but added some, and looks a little bit nicer. Koichi From kotamura at wood.odn.ne.jp Fri Aug 5 10:20:25 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Fri Aug 5 10:28:39 2005 Subject: [pangalactic-dev] Kerama core classes In-Reply-To: References: Message-ID: <20050805142835956.DPOP.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Matthias, > > property editor and wxOO > Sound's interesting, but I need more information around them. > I'll check out wxOO and BasicProperty closely. Would you give me the version info of python, wxpython, and wxOO/BasicProperty/wxpypropdist that you are using? I'm seeing a serious version conflict. How did you install it? wxoo and BasicProperty separately, or as a wxpypropdist all in one package? Koichi From nitro at dr-code.org Fri Aug 5 15:13:40 2005 From: nitro at dr-code.org (Nitro) Date: Fri Aug 5 14:42:07 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050805013633187.KWY.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050805013633187.KWY.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > I've updated "Kerama specification draft 0.8 (under construction)" > It's a draft, it's 0.8, and it's under construction. heh > http://hohehohe2.hp.infoseek.co.jp/kerama/spec/draft0.8.html > (It is not a GUI spec. If you see 'property editor', replace it > 'something which can be represented by "property editor" ') > Basically same as what we've discussed here, but added some, > and looks a little bit nicer. > > Koichi The spec looks very very good! You have done some really nice work. Some comments: 1. "Data are passed by deepcopy by default. Passing by reference is also possible." Hmm, shouldn't pass by reference be the default? This feels more pythonic, uses the reference counting and avoids unneccessary copying data. But there are perhaps some reasons against this and for making it the way you did it. 2. "" If we collapse a group node, how does it display the connections? We could make the group node a "black box" then and display a name to the connection input/output points (pins). It's kinda like a little processor with a defined interface. For example it has two inputs, number1 and number2 and one output number3. Internally the processor can either multiply number1*number2 = number3 or if you exchange the processor do number1+number2 = number3. You don't want to see all the wiring inside the processor which actually performs the mathematical operations. Kinda like what you get with an IC (integrated circuit). You can connect to the output pins, but don't have (don't need) access to the inner parts. A collapsed group could behave the same. Maybe we should have input and output pins to illustrate the connection points? Random idea: There are programs to design processors. Do they work in a similar fashion? Is there stuff we could copy? 3. "The only (not sure) difference between them is the default value of their group property 'km_exec' and 'km_propagate'." Hmmm, shouldn't we make km_exec amd km_propagate global properties? Of course we could set the values in the toplevel group node, but this would allow people to override them. This might lead to design destruction again. Maybe we should make them read-only (we should probably have the ability to simply set properties to const or read-only)? 4. "If the template node has a class (say class B), The class of its copies are also B." Should we apply similar rules to deepcopy/reference here. For example we could make the "copies" actually "references". So if you change something inside the template design it is immediately reflected in all nodes that use this template. Might cause trouble sometimes though. 5. "(Is it O.K.? It'll make it difficult to send a patch object to replace with a buggy object we've released)" If the buggy object is actually referenced and not copied like in (4) sending patches will be very easy. 6. "- Do we have a "smart node"? If we do, how do we implement it. (such as 'for' group that connects to a node automatically by drag&drop it)" Hmm, sounds good, but may be difficult to implement in practice. We could make the 'for' group like in (2) by default. It's collapsed and the internals (counter logic etc) are hidden from the user. The user is presented with a pin which takes a startValue, an endValue and an increment (very simply for loop which counts from start..end in steps of increment. We might need many more types of for loops like ones using iterators or ones that loop over lists like in python, not sure about a good solution here). It's difficult to determine how to connect the nodes if the user doesn't provide any hints. We could do something, like the user selects three nodes, then the for group gets created and is automatically connected to these three selected nodes. Not sure if that's a good idea though. Random idea: Multiple types of selections (maybe different colours)? More than one clipboard for copy'n'paste? 7. "There can be properties that are not saved to file. (Maybe specified by the propertie's name, such as 'nosave_' prefix ?)" If OnLoad/OnSave is not overriden, then Kerama will try to save all properties without the 'nosave_' prefix, otherwise it just uses the OnLoad/OnSave functions. Personally I'm against using a prefix for marking things, for example if we introduce read-only properties, then we might end up with variables like 'const_nosave_varname' which is rather ugly and everytime you want to use the variable it will enforce a lot of unneccessary typing. 8. Maybe add "Debugging" and "Profiling" to the list somewhere. Very nice work! -Matthias From kotamura at wood.odn.ne.jp Sat Aug 6 13:34:41 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sat Aug 6 13:43:05 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: References: Message-ID: <20050806174301061.HKLV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Thanks Matthias, your comments are very helpful! > Hmm, shouldn't pass by reference be the default? This feels more pythonic, > uses the reference counting and avoids unneccessary copying data. But > there are perhaps some reasons against this and for making it the way you > did it. Yeah, passing by reference is more pythonic and effective, but I think using reference is very dangerous. Once two nodes get the same reference, the nodes can pass data without connections. This means you can make an implicit data path intentionally or accidentally. One might use reference as a node design and another user who imported the node may not realize it and produces a bug. This kind of bugs are very difficult to fix since you need to check functions in the nodes throughout the node network. > 2. "" > > Kinda like > what you get with an IC (integrated circuit). You can connect to the > output pins, but don't have (don't need) access to the inner parts. A > collapsed group could behave the same. > Maybe we should have input and output pins to illustrate the connection > points? Yeah, I'm also imagining pins for property. If it is collapsed, the pins (properties) are stick on the node, and when it is expanded, the pins are stick on the window border or node border. http://hohehohe2.hp.infoseek.co.jp/kerama/collapsed_and_expanded.jpg We should at least have "collapsed" and "expanded". > Random idea: There are programs to design processors. Do they work in a > similar fashion? Is there stuff we could copy? It may have one, but the system will be quite different, I suppose... > Hmmm, shouldn't we make km_exec and km_propagate global properties? Of > course we could set the values in the toplevel group node, but this would > allow people to override them. This might lead to design destruction > again. Maybe we should make them read-only (we should probably have the > ability to simply set properties to const or read-only)? You're right! I thought we could temporarily disable one or some nodes and we can use cached data instead of waiting for time consuming calculations but I found it was completely wrong. I was aware of it's danger but tempted to have the identical two toplevel groups. Maybe we should just delete the two value from the system, i.e. static space is always inactive and execution space is always active. > 4. "If the template node has a class (say class B), The class of its > copies are also B." > Should we apply similar rules to deepcopy/reference here. For example we > could make the "copies" actually "references". So if you change something > inside the template design it is immediately reflected in all nodes that > use this template. Might cause trouble sometimes though. > 5. "(Is it O.K.? It'll make it difficult to send a patch object to > replace with a buggy object we've released)" > > If the buggy object is actually referenced and not copied like in (4) > sending patches will be very easy. Hmmm. We can have that kind of reference nodes, but I think we still need a template to be deepcopied so that we can have two nodes that can be modified separately. Similar thing to the reference nodes can be done using Kerama classes so I don't think reference node is a must have stuff (still useful if we have). About Kerama classes, it beat my brain a lot and still I'm thinking what's the right solution. If it is a reference, all the references of one default class must have the same value. But we will want to let them have their own values from project to project, not shared. It's getting a bit complicated. I'll try to make it a bit clear. Please point out if something seems wrong. Kerama nodes: -There can be multiple node objects of the same class instance in a project. -If there's one original node, and the multiple nodes are it's references, the nodes in the project will have the same property value. Kerama classes: -In one project, two class objects (named A) cannot exist. -If there's one default class A in the system, and classes in each project are the references of the original, all every A in each project will have the same property value. Default means provided by the system (i.e. provided by us). Default classes will be used in many projects. If a user make a class, it's natual to same it inside a project (or he may want to put it in his system as a plug-in, in the case, it's similar to default classes) > 6. "- Do we have a "smart node"? If we do, how do we implement it. (such > as 'for' group that connects to a node automatically by drag&drop it)" > > Hmm, sounds good, but may be difficult to implement in practice. We could > make the 'for' group like in (2) by default. It's collapsed and the > internals (counter logic etc) are hidden from the user. The user is > presented with a pin which takes a startValue, an endValue and an > increment (very simply for loop which counts from start..end in steps of > increment. We might need many more types of for loops like ones using > iterators or ones that loop over lists like in python, not sure about a > good solution here). > It's difficult to determine how to connect the nodes if the user doesn't > provide any hints. We could do something, like the user selects three > nodes, then the for group gets created and is automatically connected to > these three selected nodes. Not sure if that's a good idea though. Random > idea: Multiple types of selections (maybe different colours)? More than > one clipboard for copy'n'paste? #A big earthquake occurred now. It's the fifth time within a month. #What's happening? If I disappeared from the list, assume I'm under #debris. (just joking) Hmmm, what you've pointed out is kind of detailed problem but still it's one we can't get around. I think, create a forgroup/select multiple nodes/ drag&drop them to the group is good. We can tell what nodes to connect, ... maybe by the selection order and/or property name? I doubt if it's a good idea to have multiple clipboards, One evil temptation is that we create another function that is executed only in the "static" workspace. It is not usually visible and it's separated from a usual function so no design destruction will happen (unless it is buggy). Then we give the function really big authority to access to the system, e.g. access to a property in another node. The function is for us and some very advanced users to customize design time node/group behaviours easily, such as making smart node, group collapsing/expanding. Why it is a temptation to me is that, in the Kerama prototype, we can change the view of the node at the design time. E.g. when you see the screen snapshot, https://sourceforge.net/project/screenshots.php?group_id=142861&ssid=14786 in the center you can see a node with a text "repeat 2 times". The string is created in a function attached to the property n whose value is 2. calc.kmuser_title = "repeat " + str(calc.n) + " times" When the user set n to set the number of loops, the function is executed and the string is updated. (the system looks at kmuser_title and draws the value when a node is redrawn). We can't hardcode this function because users make their own nodes and we don't know what kind of nodes users make. Actually it is a big disadvantage we acquired when we separated static and execution workspace, in return for no design destruction. Hmmm maybe we should describe the behaviours as a hardcoded Python script, in at least next Kerama version? What do you think? > 7. "There can be properties that are not saved to file. (Maybe specified > by the propertie's name, such as 'nosave_' prefix ?)" > > If OnLoad/OnSave is not overriden, then Kerama will try to save all > properties without the 'nosave_' prefix, otherwise it just uses the > OnLoad/OnSave functions. Personally I'm against using a prefix for marking > things, for example if we introduce read-only properties, then we might > end up with variables like 'const_nosave_varname' which is rather ugly and > everytime you want to use the variable it will enforce a lot of > unneccessary typing. Ummmm. Isn't 'c_n_varname' or 'cn_varname' still not good? Using a prefix is not a must, but it'll be very non-programmer friendly. > 8. Maybe add "Debugging" and "Profiling" to the list somewhere. Right. I'll add them under "2 Kerama system". thanks > Very nice work! Thanks you:) Koichi From kotamura at wood.odn.ne.jp Sat Aug 6 13:42:18 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sat Aug 6 13:50:39 2005 Subject: [pangalactic-dev] Using the list for Kerama In-Reply-To: <20050806174301061.HKLV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050806174301061.HKLV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050806175038087.HKRB.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Steve, You kindly let me use this list but I think if you might start feeling stressed with lots of posts only for Kerama. If you feel stressed even a little bit, don't mind telling me anytime. Koichi From nitro at dr-code.org Sun Aug 7 07:58:57 2005 From: nitro at dr-code.org (Nitro) Date: Sun Aug 7 07:27:25 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050806174301061.HKLV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050806174301061.HKLV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > Thanks Matthias, your comments are very helpful! Thank you! > Yeah, passing by reference is more pythonic and effective, but I think > using reference is very dangerous. Once two nodes get the same reference, > the nodes can pass data without connections. This means you can make an > implicit data path intentionally or accidentally. One might use reference > as a node design and another user who imported the node may not realize > it > and produces a bug. This kind of bugs are very difficult to fix since you > need to check functions in the nodes throughout the node network. > Yeah, I'm also imagining pins for property. If it is collapsed, the pins > (properties) are stick on the node, and when it is expanded, the pins > are stick on the window border or node border. > http://hohehohe2.hp.infoseek.co.jp/kerama/collapsed_and_expanded.jpg > We should at least have "collapsed" and "expanded". Looks like I imagined! You just added extra pins to define the group "interface", my first idea was to set all unused group member pins as the group interface pins, but obviously this won't work (for example if there are unused output pins which should not appear in the group interface) and your approach is much better. >> 4. "If the template node has a class (say class B), The class of its >> copies are also B." > >> Should we apply similar rules to deepcopy/reference here. For example we >> could make the "copies" actually "references". So if you change >> something >> inside the template design it is immediately reflected in all nodes that >> use this template. Might cause trouble sometimes though. > >> 5. "(Is it O.K.? It'll make it difficult to send a patch object to >> replace with a buggy object we've released)" >> >> If the buggy object is actually referenced and not copied like in (4) >> sending patches will be very easy. > > Hmmm. We can have that kind of reference nodes, but I think we still > need a > template to be deepcopied so that we can have two nodes that can be > modified > separately. Similar thing to the reference nodes can be done using Kerama > classes so I don't think reference node is a must have stuff (still > useful > if we have). What's the difference between Kerama classes and templates? Currently I have no idea what Kerama classes are (which may be due to my poor understanding). I think the user should be able to choose whether he wants to use the deepcopy or the reference version when the node is created. Here's a concrete example from my planned usage of Kerama: There's a barrel class which holds all data of a barrel in the game. For example there's a member called mesh and a member called weight. Now the user instantiates two of these barrel classes. The barrel template has set a 'default.meshfile' for the mesh member and a '1' for the weight member. Now the user chooses to override 'default.meshfile' in barrel instance A with 'bigroundbarrel.meshfile'. Instance A was created with the template deepcopy method, Instance B with the reference version. Now the user changes weight in Instance B to '2'. So the current situation is: template barrel : mesh = default.meshfile, weight = 1 Instance A (deepcopied): mesh = bigroundbarrel.meshfile, weight = 1 Instance B (referenced): mesh = default.meshfile, weight = 2 Now somebody changes the default value of mesh to 'standardbarrel.meshfile'. In instance A nothing would change since it was deepcopied. However, in instance B default.meshfile will be changed, but weight will still be set to '2' because it was overridden. Albeit a little complicated, this is a very useful mechanism. For example the default.meshfile is a simple sphere, cause the barrel mesh wasn't modeled yet. When the mesh is ready, you simply patch the template and all barrels suddenly have the right mesh. It's also easy to add a third member like 'color' to the barrel template and all barrels will use it immediately. This allows you to design and test at the same time. If you don't have such a reference feature you need to delete and recreate every instantiated class when you change the underlying template. Basically this doesn't allow for iterative programming. > About Kerama classes, it beat my brain a lot and still I'm thinking > what's the > right solution. If it is a reference, all the references of one default > class > must have the same value. But we will want to let them have their own > values > from project to project, not shared. > > It's getting a bit complicated. I'll try to make it a bit clear. > Please point out if something seems wrong. > > Kerama nodes: > -There can be multiple node objects of the same class instance in a > project. > -If there's one original node, and the multiple nodes are it's > references, > the nodes in the project will have the same property value. Point 1 is correct, Point 2 not if some of the variables were overridden as I wrote in the above example. Then some values might differ. > Kerama classes: > -In one project, two class objects (named A) cannot exist. > -If there's one default class A in the system, and classes in each > project > are the references of the original, all every A in each project will > have the > same property value. Point 1 is that names are unique, that's true. I think Point 2 is also true, it's like a template-references-template. Is this equal to instance-references-template as above? > Default means provided by the system (i.e. provided by us). Default > classes will > be used in many projects. If a user make a class, it's natual to same it > inside > a project (or he may want to put it in his system as a plug-in, in the > case, > it's similar to default classes) Yes, we could make a thing like the python standard library with it. > > #A big earthquake occurred now. It's the fifth time within a month. > #What's happening? If I disappeared from the list, assume I'm under > #debris. (just joking) Oh, good luck and I hope you'll answer to this mail :) > Hmmm, what you've pointed out is kind of detailed problem but still it's > one we can't get around. I think, create a forgroup/select multiple > nodes/ > drag&drop them to the group is good. We can tell what nodes to connect, > ... > maybe by the selection order and/or property name? Yeah, I had the selection order in mind. By property name is bad as it enforces people to use special names for each variable. > I doubt if it's a good idea to have multiple clipboards, Ok, agreed, they are too cumbersome to use. > One evil temptation is that we create another function that is executed > only > in the "static" workspace. It is not usually visible and it's separated > from > a usual function so no design destruction will happen (unless it is > buggy). > Then we give the function really big authority to access to the system, > e.g. access to a property in another node. The function is for us and > some very > advanced users to customize design time node/group behaviours easily, > such > as making smart node, group collapsing/expanding. Yeah, this sounds good! We could allow for multiple of such functions that react to specific events, such as a new node creation or node deletion. Each function could deal with one node type (like a function for for-groups). We should probably make some kind of "design rules" for writing such a function. Otherwise one will use selection order, another advanced user might use variable naming, just another one the distance to next node on the canvas etc. Then the feel and easiness of the application is destroyed. If we have such rules, we can have 3rd parties easily add new nodes to the standard lib. > Why it is a temptation to me is that, in the Kerama prototype, we can > change > the view of the node at the design time. E.g. when you see the screen > snapshot, > https://sourceforge.net/project/screenshots.php?group_id=142861&ssid=14786 > in the center you can see a node with a text "repeat 2 times". The > string is > created in a function attached to the property n whose value is 2. > > calc.kmuser_title = "repeat " + str(calc.n) + " times" > > When the user set n to set the number of loops, the function is executed > and the string is updated. (the system looks at kmuser_title and draws > the > value when a node is redrawn). > We can't hardcode this function because users make their own nodes and > we don't > know what kind of nodes users make. Actually it is a big disadvantage we > acquired when we separated static and execution workspace, in return for > no > design destruction. Yes, you are right. However, we could probably overcome this disadvantage. We could allow write access to special properties like kmuser_title in the static workspace. Design destruction can still happen, but maybe the benefit of being able to modify the title is bigger than the disadvantage caused by design destruction. Of course you can read access any property you like. > Hmmm maybe we should describe the behaviours as a hardcoded Python > script, > in at least next Kerama version? What do you think? Hmm, which behaviours do you want to hardcode? > Ummmm. Isn't 'c_n_varname' or 'cn_varname' still not good? > Using a prefix is not a must, but it'll be very non-programmer friendly. Yes, it's very non-programmer friendly, but has one big drawback. Say you create a c_n_variable and code lots of nodes with it. Then you decide that you want to be able to save the variable, so you need to rename the var to c_variable in all places where you've used it! This is lots of work ... Which leads me to another question in respect to referenced templates. What will happen if you rename the 'weight' member to 'Weight' for instance? Will all the code using this var change the varname automatically or will you need to do that by hand? Because it's Python it's quite hard to auto-rename the vars. This is a very interesting discussion and I see you've put lots of brainwork into it! -Matthias From kotamura at wood.odn.ne.jp Mon Aug 8 08:32:11 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Mon Aug 8 08:40:30 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: References: Message-ID: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Hi, > What's the difference between Kerama classes and templates? Currently I > have no idea what Kerama classes are (which may be due to my poor > understanding). My concept of Kerama class, template, and node are like this. It's quite similar to your idea. Here I used the term 'template' as '(object) to be deepcopied', and wrote 'Kerama class' just as 'class' where it is not ambiguous. 1. Only nodes can exist in the diagram, not classes. 2. Basically the relation ship between Kerama class nad node is the same as Python class and object. When a node is instanciated from a class, every class property is inherited to the node. For example, say there's aclass C_B that has properties input_a and input_b, and node N_B is an instance of class C_B class C_B: (property) input_a input_b node N_B: (property) Then input_a and input_b is inherited from C_B to N_B. 3. A node can override class properties. class C_B: (property) input_a input_b node N_B: (property) input_a in this case input_b is inherited from C_B. While N_B has it's own property input_a, so input_a is overrided. N_B can have it's own value of input_a. 4. If a class property has a function attached, it is also inherited to the node. class C_B: (property) (function) input_a output_a = input_a + input_b input_b output_a node N_B: (property) (function) input_a output_a then when the value of N_B::input_a changes, the value of N_B::output_a will be N_B::input_a + C_B::input_b. 5. You can also override functions. class C_B: (property) (function) input_a output_a = input_a + input_b input_b output_a node N_B: (property) (function) input_a output_a = input_a * input_b output_a then when the value of N_B::input_a changes, the value of N_B::output_a will be N_B::input_a * C_B::input_b. 6. An object (either class or node) must have a property to create a function. You can do like this. class C_B: (property) (function) output_a = input_a + input_b #function for instance's input_a node N_B: (property) (function) input_a input_b output_a 7. class C_B: Class property is not changed simply by assigning a value. (property) (function) input_a output_a = input_a * input_b output_a node N_B: (property) (function) input_a input_b when a value is set to N_B::input_a, the function is executed, and causes error since N_B::output_a doesn't exists (C_B::output_a will not change). C_B::otuput_a will be changed using a function km_ChangeClassProperty() or sth. (that's what I haven't written in the draft) 8. To make 7. work you must create N_B::output_a. (property) (function) input_a output_a = input_a * input_b output_a node N_B: (property) (function) input_a input_b output_a 9. You can make N_B once and register it as a template. Once the template is registered, you can create the copy of N_B as many as you like by deepcopying it(by drag&drop N_B template in the GUI). 10. A class can have superclasses, just like Python, (but multiple inheritance is not supported). > > About Kerama classes, it beat my brain a lot and still I'm thinking > > what's the > > right solution. If it is a reference, all the references of one default > > class > > must have the same value. But we will want to let them have their own > > values > > from project to project, not shared. > Point 1 is correct, Point 2 not if some of the variables were overridden > as I wrote in the above example. Then some values might differ. > Point 1 is that names are unique, that's true. I think Point 2 is also > true, it's like a template-references-template. Is this equal to > instance-references-template as above? When define a node, template, class like above, we need to choose what objects to be saved to a project file. We will want to save nodes in the diagram, of course. Template nodes: probabley we want. Classes, same as template. If we want to use the templates and/or classes in another project, we can export and import it. If we want to use them in lots of other projects, we can export and put the exported file to the Kerama plug-in folder, and we can use them in any project just like default classes/templates. Once a class is used. the class will be saved to the project, otherwise the values of class properties will be lost. But if we found a buggy class is exported, we may want to send a bug-fixed version of the class and we want the class to be used where ever the class is used. I'm having difficulty how we can do it. I hope we can find a good way to do it. I wonder if there's a good versioning system for it. > Yeah, I had the selection order in mind. By property name is bad as it > enforces people to use special names for each variable. I thought this can be a naming convention, but I'm not sure, it may be a bad idea. > > Ummmm. Isn't 'c_n_varname' or 'cn_varname' still not good? > > Using a prefix is not a must, but it'll be very non-programmer friendly. > so you need to rename the var to > c_variable in all places where you've used it! This is lots of work ... Ahhh! You're right! Thank for pointing it out. It's no more an option. I'll write my detailed opinion about making another function and renaming at another mail. Koichi From kotamura at wood.odn.ne.jp Mon Aug 8 11:50:58 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Mon Aug 8 11:59:14 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050808155911735.POYQ.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > But if we found a buggy class is exported, we may want to send a bug-fixed > version of the class and we want the class to be used where ever the class > is used. I'm having difficulty how we can do it. I hope we can find a good > way to do it. I wonder if there's a good versioning system for it. Hmmm, we may have to give up sending a patch object. In general, you can send a patch only when interfaces are not changed. For Kerama classes/templates/nodes, interfaces are properties, and a user can freely add/remove properties or change the meaning of the property. To be able to send a patch, we need to make something like 'finalized flag'. If the flag is set to an object, you can not change (add/remove properties) the object anymore. So it is a 'const' object. But a class whose value is constant is not easy to use ... > Yeah, this sounds good! We could allow for multiple of such functions that > react to specific events, such as a new node creation or node deletion. > Each function could deal with one node type (like a function for > for-groups). We should probably make some kind of "design rules" for > writing such a function. Otherwise one will use selection order, another > advanced user might use variable naming, just another one the distance to > next node on the canvas etc. Then the feel and easiness of the application > is destroyed. If we have such rules, we can have 3rd parties easily add > new nodes to the standard lib. Oops, the hidden functions must be effective, otherwise the look&feel of nodes will be different between static workspace and execution workspace. I thought more raw event such as 'on double clikced'. In the function we can do anything, new node creation, node deletion ... And I think it's a good idea to have such functions in a super class (one of the super classes in the class hierarchy). "design rules" will be a good idea if we have that kind of functions. I should explain why I'm not sure if we should have that kind of functions. The functions are so strong, so people (like me!) will start making tricky nodes/classes. If one make a node that temporarily make a connection to other nodes during it's execution time, it's never be easy for people to understand the node network, What do you think? Maybe it's enough to say just 'follow the rules'? If we have the functions, it'll be possible to have some 'refactoring' nodes, e.g. renaming a property name to another so all the 'weight' property becomes 'Weight'. > > Hmmm maybe we should describe the behaviours as a hardcoded Python > > script, > > in at least next Kerama version? What do you think? > > Hmm, which behaviours do you want to hardcode? Ah I mean, if every 'new node creation' should be hardcoded or not, so if we should have hidden functions or not. Koichi From kotamura at wood.odn.ne.jp Mon Aug 8 13:57:08 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Mon Aug 8 14:05:24 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050808155911735.POYQ.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050808155911735.POYQ.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050808180522406.PTCT.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > Oops, the hidden functions must be effective, otherwise the look&feel of > nodes will be different between static workspace and execution workspace. > I thought more raw event such as 'on double clikced'. I mean the hidden functions must be also effective in the execution space. Koichi From kotamura at wood.odn.ne.jp Mon Aug 8 14:46:39 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Mon Aug 8 14:54:56 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050808185453653.PTZW.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > 6. > An object (either class or node) must have a property to create a function. > You can do like this. > > class C_B: > (property) (function) > output_a = input_a + input_b #function for instance's input_a > > node N_B: > (property) (function) > input_a > input_b > output_a You CANNOT do like this. Another typo, sorry. Koichi From nitro at dr-code.org Tue Aug 9 04:14:26 2005 From: nitro at dr-code.org (Nitro) Date: Tue Aug 9 03:42:52 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050808155911735.POYQ.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> <20050808155911735.POYQ.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > Hmmm, we may have to give up sending a patch object. In general, you can > send > a patch only when interfaces are not changed. For Kerama > classes/templates/nodes, > interfaces are properties, and a user can freely add/remove properties > or change > the meaning of the property. > To be able to send a patch, we need to make something like 'finalized > flag'. > If the flag is set to an object, you can not change (add/remove > properties) the > object anymore. So it is a 'const' object. But a class whose value is > constant > is not easy to use ... Hmm, you are right. It's a bad system for sending patches. What about that barrel example though where you "patch" your own objects? It would be useful if a patch could modify the other side of the interface, too (unless the modification is too heavy and requires deeper investigation by the user). I think we need some mechanism for the kind of workflow that I outlined in the barrel example. If I "patch" my template then this change should propagate through all nodes using the template. If the interface is changed (for example a property removed) we could highlight all those places on the canvas so that the user can see immediately where he needs to chnage connections etc.. If you don't allow the changes to the template and thus to all nodes of that kind, it's not very useful anymore and you would need to update every single node by hand which is very very cumbersome. There are always two sides for an interface and if you modify the first you also need to modify the second. So there will always be at least 2 patches (it's really an 1:n relationship) which need to work together. For example if you have 10 barrel nodes and 10 barrel user and 10 barrel special user nodes which use the barrel interface, you need to make 30 patches. Easiest would be to modify the 3 templates and apply them to all 30 nodes. I think a patch should not have the requirement that it doesn't break code. It should be allowed to break it. Maybe we can have two categories of patches. One where the patches are allowed to break code and one where not. The standard library should use category "break not" in minor releases like 1.1 - 1.2 - 1.7, but it's allowed to break interfaces and use category 1 patches in major releases like 2.0 - 3.0 - 7.0. If you never allow to fix the interfaces the kerama lib will get stuck in horrible hacks to work around old bugs. I've seen this with many other projects. I am using a tool called "cegui" (www.cegui.org.uk) where they break backwards-compatability with almost every release. It requires more work from the user, but the user benefits a lot from it. The library remains clean and robust. Maybe we should break the standard lib in the alpha/beta phase just as we need to and when it comes to the 1.0 release get a little more conservative and deliver non-breaking patches. When introducing radical new features and change kerama a lot, we should also be allowed to break the old standard lib. What do you think? > Oops, the hidden functions must be effective, otherwise the look&feel of > nodes will be different between static workspace and execution workspace. > I thought more raw event such as 'on double clikced'. In the function > we can do anything, new node creation, node deletion ... And I think > it's a good idea to have such functions in a super class (one of the > super > classes in the class hierarchy). > "design rules" will be a good idea if we have that kind of functions. > I should explain why I'm not sure if we should have that kind of > functions. > The functions are so strong, so people (like me!) will start making > tricky > nodes/classes. If one make a node that temporarily make a connection to > other > nodes during it's execution time, it's never be easy for people to > understand > the node network, What do you think? Maybe it's enough to say just > 'follow the > rules'? Ok, it's much better to do the stuff more low-level as you said and allows for more customization (like assigning different keys to different actions). I think we should manifest some of the most important rules into code which prevent actions like creating a temporary connection during execution time. Temporary connections during execution time are an interesting point. I haven't thought about them so far. Do you think there might be places where you can't get around them or where they might be very handy to use? I agree that they are very uneasy, so we should decide this problem with caution. >> > Hmmm maybe we should describe the behaviours as a hardcoded Python >> > script, >> > in at least next Kerama version? What do you think? >> >> Hmm, which behaviours do you want to hardcode? > > Ah I mean, if every 'new node creation' should be hardcoded or not, so > if we > should have hidden functions or not. I'm for these hidden functions. If we decide against them, we can still make them non-accessible or const for users in some way. They might be great for fast development and testing features, too. From nitro at dr-code.org Tue Aug 9 04:25:29 2005 From: nitro at dr-code.org (Nitro) Date: Tue Aug 9 03:53:53 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050808124025453.OQCL.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > 7. > class C_B: > Class property is not changed simply by assigning a value. > > (property) (function) > input_a output_a = input_a * input_b > output_a > > node N_B: > (property) (function) > input_a > input_b > > when a value is set to N_B::input_a, the function is executed, and causes > error since N_B::output_a doesn't exists (C_B::output_a will not change). > C_B::otuput_a will be changed using a function km_ChangeClassProperty() > or sth. (that's what I haven't written in the draft) In your example N_B would inherit output_a from C_B and thus it exists and you could set it. Or did I miss something important? > 8. > To make 7. work you must create N_B::output_a. > > (property) (function) > input_a output_a = input_a * input_b > output_a > > node N_B: > (property) (function) > input_a > input_b > output_a So you need to override output_a explicitly in N_B in order to use it or is it enough to inherit it from C_B (see my comment to point 7)? > 10. > A class can have superclasses, just like Python, (but multiple > inheritance is > not supported). Is fully-orthogonal multiple inheritance also not supported? It's quite useful for mixins and other things and I use it frequently as it allows you to compose classes in an easy way. Probably it's too complicated for beginners and they should not use it until they got familiar with the system. But then it's a powerful tool I wouldn't want to miss. Random idea: Maybe have two modes which kerama can run in (easy and full-power)? Maybe not very useful though. > But if we found a buggy class is exported, we may want to send a > bug-fixed > version of the class and we want the class to be used where ever the > class > is used. I'm having difficulty how we can do it. I hope we can find a > good > way to do it. I wonder if there's a good versioning system for it. Yeah, I agree with you. See my other mail. If we highlight all changes and where adoption needs to take place, then it's probably very easy to use and patch things. >> Yeah, I had the selection order in mind. By property name is bad as it >> enforces people to use special names for each variable. > > I thought this can be a naming convention, but I'm not sure, it may be a > bad idea. Yeah, any naming convention might lead to the problem about renaming variables. > I'll write my detailed opinion about making another function and renaming > at another mail. Ok. -Matthias From kotamura at wood.odn.ne.jp Tue Aug 9 17:07:14 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Tue Aug 9 17:15:33 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: References: Message-ID: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Hi, > > 7. > > class C_B: > > Class property is not changed simply by assigning a value. > > > > (property) (function) > > input_a output_a = input_a * input_b > > output_a > > > > node N_B: > > (property) (function) > > input_a > > input_b > > > > when a value is set to N_B::input_a, the function is executed, and causes > > error since N_B::output_a doesn't exists (C_B::output_a will not change). > > C_B::otuput_a will be changed using a function km_ChangeClassProperty() > > or sth. (that's what I haven't written in the draft) > > In your example N_B would inherit output_a from C_B and thus it exists and > you could set it. Or did I miss something important? Oops, sorry. I missed writing some. class C_B's namespace has input_a and output_a, and node N_B's namespace has input_a and input_b. N_B is an instance of C_B so output_a and input_a's function are inherited from C_B. You can see output_a but cannot set value to it without using km_ChangeClassProperty(). It's related to > 1. > Only nodes can exist in the diagram, not classes. Whenever a function is executed, a correspondent node (not class) exists and the function take effects to the node. (unless you use km_ChangeClassProperty) I've thought about the design where classes can be on the diagram and they can be connected. But concluded it only increased confusion. > > 8. > So you need to override output_a explicitly in N_B in order to use it or > is it enough to inherit it from C_B (see my comment to point 7)? In this case, you need to override output_a explicitly. > > 10. > > A class can have superclasses, just like Python, (but multiple > > inheritance is > > not supported). > > Is fully-orthogonal multiple inheritance also not supported? It's quite > useful for mixins and other things and I use it frequently as it allows > you to compose classes in an easy way. Probably it's too complicated for > beginners and they should not use it until they got familiar with the > system. But then it's a powerful tool I wouldn't want to miss. Random > idea: Maybe have two modes which kerama can run in (easy and full-power)? > Maybe not very useful though. I don't mind having fully-orthogonal multiple inheritance if we can find a good GUI for it (sounds silly but important). Basically I'm not for having easy mode. I often see people get confused by that mode. And that's why I don't like having hidden properties. Hidden properties also makes people confused (not about the super powered functions we've discussed recently. We can have powered mode and hidden properties, or whatever). > Yeah, any naming convention might lead to the problem about renaming > variables. O.K. Maybe you are right. > I think we need some mechanism for the kind of workflow that I outlined in > the barrel example. If I "patch" my template then this change should > propagate through all nodes using the template. If the interface is > changed (for example a property removed) we could highlight all those > places on the canvas so that the user can see immediately where he needs > to chnage connections etc.. If you don't allow the changes to the template > and thus to all nodes of that kind, it's not very useful anymore and you > would need to update every single node by hand which is very very > cumbersome. > There are always two sides for an interface and if you modify the first > you also need to modify the second. So there will always be at least 2 > patches (it's really an 1:n relationship) which need to work together. For > example if you have 10 barrel nodes and 10 barrel user and 10 barrel > special user nodes which use the barrel interface, you need to make 30 > patches. Easiest would be to modify the 3 templates and apply them to all > 30 nodes. O.K. I was thinking of making a reference node that behaves like that for that need, apart from templates. But making a template have a roll as a reference original is not a bad idea. Your barrel example looks good where template can be either deepcopied or referenced. Before I was not for the idea cause I assumed a template as a constant object but I've changed my mind thinking of the following application design. My current idea is like this: We have class hierarchy, a set of templates, node diagrams both for static workspace and execution workspace. So the system has two class hierarcies, two set of templates, two node diagrams. class hierarchy -- for the static workspace set of templates -- for the static workspace nodes -- for the static workspace class hierarchy -- for the execution workspace set of templates -- for the execution workspace nodes -- for the execution workspace I found we need two class hierarchies to prevent design destruction because classes are not constant. Classes, templates, nodes all have an influence on the execution behaviour in the execution workspace, and in the static workspace if they have super powered functions. A default set of classes/templates prepared by the system can be added to the classes/templates either for the static workspace or for the execution workspace. It's not what I had imagined first, but not bad I think. (Hmmm, looks it may be contradictory to your idea reading the next part) > I think a patch should not have the requirement that it doesn't break > code. It should be allowed to break it. Maybe we can have two categories > of patches. One where the patches are allowed to break code and one where > not. The standard library should use category "break not" in minor > releases like 1.1 - 1.2 - 1.7, but it's allowed to break interfaces and > use category 1 patches in major releases like 2.0 - 3.0 - 7.0. If you > never allow to fix the interfaces the kerama lib will get stuck in > horrible hacks to work around old bugs. I've seen this with many other > projects. I am using a tool called "cegui" (www.cegui.org.uk) where they > break backwards-compatability with almost every release. It requires more > work from the user, but the user benefits a lot from it. The library > remains clean and robust. Maybe we should break the standard lib in the > alpha/beta phase just as we need to and when it comes to the 1.0 release > get a little more conservative and deliver non-breaking patches. > When introducing radical new features and change kerama a lot, we should > also be allowed to break the old standard lib. > > What do you think? Basically I'm for the idea in general, especially about the alpha/beta and 1.0 release, but I'm a bit confused about category "break not". - When you release a class or a template (say A), A will be put in the user's Kerama system. - When the user makes a project and uses A, A must be copied, otherwise A will be shared among all projects that uses A, and changes to A done in one project will be reflected to all the other projects. - A will be copied, so the copy will be saved to the project file, otherwise chages to A will be lost. - When a project file is opened, we can check if updated version of A exists, but A may not be what it was when it was released, because the user can remove properties. So even if the interface of the patch object is the same as the interface of old released object, we can't expect it doesn't break code. Is this right? If this is true, the object publisher need to define what is the 'interface' of the object to release "break not" object, e.g. if he define that property 'a' is an interface, the user can't remove it. (It may also be wrong) > Ok, it's much better to do the stuff more low-level as you said and allows > for more customization (like assigning different keys to different > actions). It leads to the idea that we can make a node that represents menu, tree, status bar, etc. We need to draw a line somewhere between the items shown below with regard to what to implement. a) super powered node b) super powered node that represents menu, tree, status bar... c) super powered node that represents connections d) super powered node that creates menu, tree, status bar controls... e) super powered node that defines Kerama core system. d) is close to what I said 'run Kerama on Kerama'. e) means we have a minimum execution system and every other things (not only GUI and it's event handlers) run on the system. I'm for a), against c), not sure about b) and d), definitely against e) since e) needs vast amount of additional concept work. I'd rather look at Kerama run on my machine. > I think we should manifest some of the most important rules into > code which prevent actions like creating a temporary connection during > execution time. > Temporary connections during execution time are an interesting point. I > haven't thought about them so far. Do you think there might be places > where you can't get around them or where they might be very handy to use? > I agree that they are very uneasy, so we should decide this problem with > caution. Hmmmmmmmmmmmmmmmmmm. I was also thinking about it after the last mail. It is uneasy, on the other hand it is very useful when you are make an application that has a diagram such as 'CVS client with GUI'. > > Ah I mean, if every 'new node creation' should be hardcoded or not, so > > if we > > should have hidden functions or not. > > I'm for these hidden functions. If we decide against them, we can still > make them non-accessible or const for users in some way. They might be > great for fast development and testing features, too. O.K. Let's go on! Koichi From kotamura at wood.odn.ne.jp Tue Aug 9 17:25:20 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Tue Aug 9 17:33:39 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050809213335473.UDRV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > a) super powered node > b) super powered node that represents menu, tree, status bar... > c) super powered node that represents connections > d) super powered node that creates menu, tree, status bar controls... > e) super powered node that defines Kerama core system. I used the term 'super powered node' meaning 'a node that has super powered functions'. How do we call it? I couldn't create a good naming for it. a) means just having these functions. Koichi From kotamura at wood.odn.ne.jp Wed Aug 10 15:30:02 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Wed Aug 10 15:38:19 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050810193817086.YFNK.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> > d) is close to what I said 'run Kerama on Kerama'. This is some more details I have in my head ... When Kerama is started, it can automatically runs a project and its startpoint can be specified by its argument. You specify a project that creates GUI. kerama -project="keramaGui.prj" (kerama command itself doesn't create any GUI) In the GUI project, the main wxPython frame is created, then menu, statusbar, and other windows, controls, ... http://hohehohe2.hp.infoseek.co.jp/kerama/guidiagram.jpg When keramaGUI started execution, after some initialization process, a value is set to the trigger property mainGUI.create (mainGUI is a groupnode). In the functions in the mainGUI node, wxPython main frame is created. When it is done, any value is set to mainGUI.done, which is connected to menuBar.create and statusBar.create that are trigger properties to create correstpondent GUI components. mainGUI and other GUI nodes also have event handler properties. They are set value when GUI event is produced on the component. Idealy, keramaGui.prj will create another main GUI when it is loaded from Kerama application that is already started, so that we can develop Kerama GUI on Kerama. And it will be a main GUI if Kerama is started with -project="keramaGui.prj". (Again idealy ) we can make any kind of application that works on Kerama and that has GUI in this way. Finally we may even change the behavior of the GUI when we edit them. When we drag a button in another Kerama window that is currently being developed, we can change the position of the button. One might want to make such generic GUI editor. We should have another toplevel execution workspace to hold the gui diagram. If you are for the idea, my idea about development is, we first develop Kerama without using this, i.e. every GUI is hardcoded. It is Kerama 1.0. Then we start making Kerama 2.0 which has this kind of dinamic GUI. We will have lots of things to be implemented, developing both Kerama itself and KeramaGUI that works on Kerama will be difficult. What do you think? Koichi From kotamura at wood.odn.ne.jp Fri Aug 12 15:57:33 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Fri Aug 12 16:05:56 2005 Subject: [pangalactic-dev] about GUI design Message-ID: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> I drew a couple of charts. 1. My Image of property namespace implementation is like this. http://hohehohe2.hp.infoseek.co.jp/kerama/misc/namespaceimpl.jpg (Not a UML. I don't know how I can draw classes in UML) Arrows are references. Either direct reference or through other objects such as ICU. I'm wondering if we can make the namespace object for templates similary. What do you think? 2. Again about > d) is close to what I said 'run Kerama on Kerama'. http://hohehohe2.hp.infoseek.co.jp/kerama/konk/index-eng.html I'm not for the idea of implementing it to the next version, still it'll be good for brain execise :) Koichi From kotamura at wood.odn.ne.jp Sat Aug 13 13:27:51 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sat Aug 13 13:36:20 2005 Subject: [pangalactic-dev] several questions about Pan Galactic Message-ID: <20050813173616499.JJMV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Matthias, Would you give me the version info of your wxoo and BasicTypes/BasicProperty, wxWidgets, and Python? I tried to install wxoo and tested lots of combinations from olds one to new ones, but still suffering from the nasty version conflict. Could be aother reason but version conflict is most likely... Koichi From kotamura at wood.odn.ne.jp Sat Aug 13 21:02:03 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sat Aug 13 21:10:29 2005 Subject: [pangalactic-dev] about GUI design Message-ID: <20050814011026661.JVSH.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Matthias, > There's a barrel class > which holds all data of a barrel in the game. For example there's a member > called mesh and a member called weight. Now the user instantiates two of > these barrel classes. The barrel template has set a 'default.meshfile' for > the mesh member and a '1' for the weight member. Now the user chooses to > override 'default.meshfile' in barrel instance A with > 'bigroundbarrel.meshfile'. Instance A was created with the template > deepcopy method, Instance B with the reference version. Now the user > changes weight in Instance B to '2'. So the current situation is: > > template barrel : mesh = default.meshfile, weight = 1 > Instance A (deepcopied): mesh = bigroundbarrel.meshfile, weight = 1 > Instance B (referenced): mesh = default.meshfile, weight = 2 > > Now somebody changes the default value of mesh to > 'standardbarrel.meshfile'. In instance A nothing would change since it was > deepcopied. However, in instance B default.meshfile will be changed, but > weight will still be set to '2' because it was overridden. Ummm. I may be still misunderstanding. - Can we change the value of property 'mesh' in Instance B without overriding the property? If we can, is value of 'mesh' property in the template changed? - Can we put the template in the diagram? - Can we change the value of 'mesh' property of the template during execution time? If we can't change the value of 'mesh' without overriding it and we can't put the template in the diagram, can we represent the template - instance relationship with kerama class and node? Koichi From kotamura at wood.odn.ne.jp Sun Aug 14 01:57:50 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sun Aug 14 02:06:11 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050814060607858.KNZN.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> What do you think about the idea of a node having multiple groups? http://hohehohe2.hp.infoseek.co.jp/kerama/misc/grouplayer.jpg The groups can be represented like a layer. I think if a class can also have groups like this and can be inherited/overrided by the subclasses/nodes so that we can mimic object composition. For example, first we have a node (node A) which is mainly implemented inside its group. If we want to have two different nodes (node B, node C) which functions are similar to node A, we can change node A to a class (say, class A), and we can make node B, C that are delived from class A. Also if we can represent inheritance as overlapped layers, we can make it very intuitive. I have now two questions if Kerama has this feature: - Does a property come with a group, or a node? - How can we implement a group. Maybe we will want to use Python class-instance namespace. Is it possible? I haven't been thinking about it a lot (just a few hours), so it may have some problems especially associated with override. Kochi From golux at comcast.net Mon Aug 15 15:24:24 2005 From: golux at comcast.net (Stephen Waterbury) Date: Mon Aug 15 15:24:15 2005 Subject: [pangalactic-dev] several questions about Pan Galactic In-Reply-To: <20050815182407869.WISK.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> References: <20050815182407869.WISK.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Message-ID: <4300EBE8.7070408@comcast.net> Koichi Tamura wrote: >><-- Document-like ................................... Model-like --> >> >>[pure text] [structured text] [XML] [things with schemas] [CAD/CAE] >> >>This is very sketchy (many more kinds of things can go in the spectrum), >>but gives you the general idea. When you get around the middle of the >>spectrum, it is somewhat arbitrary, or at least application-dependent, >>what you consider a Document and what you consider a Model. > > Who dicides what type of data into which? Each software application decides -- determined by its end-users' preferred view of the data or document. This diagram is only conceptual, and the "types" (pure text, structured text, etc.) are just approximate concepts. There are, of course, lots of standard ways to do things at all points in the spectrum. How a particular application object is represented depends on the application's area of interest and how much information it needs. > My concern is, if two offices (or department of NASA) makes different decision > on one type of data (one department looks at it as a Document, another as a > Model), it will make confusion if the two offices are merged. Indeed, that is so. One of the purposes of PanGalactic is to enable an application to use whatever standard is appropriate for its area of interest, and accomplish any necessary merging, transformation, or integration of data and objects by way of mappings between the types of representations . That is part of the reason why I'm doing so much work at the meta level in PanGalactic, since that's where such mappings must be implemented. The bottom line for "merging" (or simply exchanging, archiving, etc.) data from different departments that look at the data differently is that a PanGalactic application must know which standard is being used by each department and must have a mapping between the contents of the documents and data sets that correspond. Confusion arises when an application does not have that information -- or, perhaps even more frequently, when an application is not even able to handle more than one standard representation or data format, as is often that case for applications whose users are only interested in a very simple view or a very homogeneous data population. > You may have a standard for it but I think it's quite difficult to make a > standard to all application-dependent data types. > It'll be nice if you have the answer to this, preparing for the time > Pan Galactic is released. As I say, my approach is at the meta-level, similar to the OMG's "Meta Object Facility". The primary standards that I am trying to make PanGalactic support are OWL/RDF (for such things as the Dublin Core, and any other ontology-based schema), STEP (ISO 10303, the CAD/CAE data exchange standard), and UML/SysML (for models of software and systems). There will be other important standards, but if in my initial release I can support those 3, and be able to transform and integrate data objects received from any of them, I'll be very happy. > By the way, are you still interested in Kerama? (I hope so) Yes. Sorry I've been out of touch lately -- I was on a one-week cruise last week and it really put me behind all my work, not to mention email correspondence. I've been skimming your messages but haven't responded because I have to stay focused on implementing PanGalactic's ObjectSchema using Zope Interfaces, and that's all my over-heated little brain can handle for now! ;) Hopefully I'll get to a point soon where I can start looking at how it will fit together with Kerama. Sounds like you are making progress on the architecture concepts ... keep it up! Cheers, Steve From kotamura at wood.odn.ne.jp Tue Aug 16 15:23:40 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Tue Aug 16 15:32:04 2005 Subject: [pangalactic-dev] several questions about Pan Galactic In-Reply-To: <4300EBE8.7070408@comcast.net> References: <4300EBE8.7070408@comcast.net> Message-ID: <20050816193201106.FGP.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Steve, Ah, I see you are well prepared both theoretically and practically. For example, STEP are a standard for CAD/CAE data exchange so I guess it looks at data as a structured set of minimum size data blobs. Or STEP might only provide the way of "how an application can reach the data blobs", and it may be the role of each application to decide the structure (it's more likely). Anyway, so Pan Galactic also holds information on engeneering data/documents without loseing its structures and relationships between them (or freely create its structures and relationships between them asking each application's need), and any STEP compliant applications can use Pan Galactic directly without any stress. I can say very abstractively because that's all I understand, but I gradually begin to understand "What is Pan Galactic" (although very slowly :) > Yes. Sorry I've been out of touch lately -- I was on a one-week > cruise last week and it really put me behind all my work, not to > mention email correspondence. I've been skimming your messages > but haven't responded because I have to stay focused on > implementing PanGalactic's ObjectSchema using Zope Interfaces, > and that's all my over-heated little brain can handle for now! ;) > > Hopefully I'll get to a point soon where I can start looking at how > it will fit together with Kerama. Sounds like you are making progress > on the architecture concepts ... keep it up! That's great to hear that :):):) I think it's good anybody who commits to Kerama does it at his own pace and with his own preference to do it, so Kerama can grow up steadily in the long run. Ah, and I'm recently making/changing the cocepts rapidly as if I'm "going my way". You guys can interrupt anytime/anywhere if something sounds wrong or weird, cause Kerama is currently on the brainstorming stage. Koichi From kotamura at wood.odn.ne.jp Wed Aug 17 09:50:19 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Wed Aug 17 09:58:44 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050814060607858.KNZN.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050814060607858.KNZN.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: <20050817135839566.DTWW.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> > What do you think about the idea of a node having multiple groups? > http://hohehohe2.hp.infoseek.co.jp/kerama/misc/grouplayer.jpg Hmmm, maybe it'not a good idea... From kotamura at wood.odn.ne.jp Thu Aug 18 15:18:42 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Thu Aug 18 15:27:13 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050817135839566.DTWW.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> References: <20050817135839566.DTWW.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Message-ID: <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Hi, I'm thinking if we should have a node that deals with GUI objects(node, connection, class, ...). The node has GUI related properties and powered functions that defines GUI behaviour of the correspondant object. My gedankenexperiment is like this: -We can define a node's gui behaviours in its powered functions. -If we can do it, we want to define a connection's gui behavioiurs in the same way. -A connection doesn't have properties nor functions, so we need a node for the connection GUI. -We need another execution workspace for it to place the node. --- (A) -If a connection has a node that deals with the connections's GUI representation, It's natural we have a node that deals with "a node's GUI representation", i.e. we separate a node's GUI representation from the node itself. -If we have both "connection GUI" node and "node GUI" node, it's natural we put them in the same workspace (A). Node (intrinsic one) itself has only a property which specifies the type of the "GUI node", and when the node is to be edited in the GUI, the Kerama system creates an appropriate GUI node for the (intrinsic) node. A set of default GUI node is prepared in the Kerama GUI system and can be added freely. It has both pros and cons. Pros: - Connections, Classes can be customized easily. - Can separate node intrinsic properties and it's GUI related properties. Cons: - Need another workspace. - We want to edit the space (A), so we need a GUI to edit it, it means we need yet another workspace. So we need two more workspaces in total. - Not so simple. If a node has a powered function for its GUI in itself, it'll be more intuitive. - Kerama core will be a little bit complicated. What do you thing? Koichi From kotamura at wood.odn.ne.jp Sat Aug 20 12:08:46 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sat Aug 20 12:17:26 2005 Subject: [pangalactic-dev] Data passing by reference (Kerama) Message-ID: <20050820161709037.XCZA.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Matthias, > Hmm, shouldn't pass by reference be the default? This feels more pythonic, > uses the reference counting and avoids unneccessary copying data. But > there are perhaps some reasons against this and for making it the way you > did it. I rethought about it. It'd be good if we have a group property "passByReference" ,and data are all passed by reference inside the group by default. We should be careful so that people will not be confused though, since apart from the hidden data path problem, passing by reference can make circular references very easily. One of the way to make people cautious will be: - Change the way of expanding the group. (e.g. shift + double cliking the node). - If you try you expand the group in the usual way (double cliking the node), a warning message box pops up. - If you try to put a node that is flagged "passByReference" (i.e. passByReference group property is True), in a non-flagged group, a warning message box pops up. Koichi From kotamura at wood.odn.ne.jp Sun Aug 21 12:55:28 2005 From: kotamura at wood.odn.ne.jp (Koichi Tamura) Date: Sun Aug 21 13:04:05 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> References: <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Message-ID: <20050821170356511.OKL.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> > I'm thinking if we should have a node that deals with GUI > objects(node, connection, class, ...). > The node has GUI related properties and powered functions that > defines GUI behaviour of the correspondant object. > Cons: > - We want to edit the space (A), so we need a GUI to edit it, > it means we need yet another workspace. So we need two more workspaces in > total. Hmmm, it's not true. "GUI object" node can be edited using the GUI itself. I hope I can release "Kerama specification draft 0.81-alpha (under construction)" next month. I can't do any more job this month cause I'm going to Kerama!!!!!!!! Koichi From nitro at dr-code.org Wed Aug 31 09:30:47 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 08:54:32 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > I don't mind having fully-orthogonal multiple inheritance if we can find > a good GUI for it (sounds silly but important). > Basically I'm not for having easy mode. I often see people get confused > by > that mode. And that's why I don't like having hidden properties. > Hidden properties also makes people confused (not about the super powered > functions we've discussed recently. We can have powered mode and hidden > properties, or whatever). Maybe the easy mode doesn't hide anything, it just doesn't allow you to use multiple inheritance. Sounds not like a good idea though, let's forget about it. > O.K. I was thinking of making a reference node that behaves like that > for that > need, apart from templates. But making a template have a roll as a > reference > original is not a bad idea. Your barrel example looks good where template > can be either deepcopied or referenced. Before I was not for the idea > cause > I assumed a template as a constant object but I've changed my mind > thinking of > the following application design. > > My current idea is like this: > > We have class hierarchy, a set of templates, node diagrams both for > static > workspace and execution workspace. So the system has two class > hierarcies, > two set of templates, two node diagrams. > > class hierarchy -- for the static workspace > set of templates -- for the static workspace > nodes -- for the static workspace > class hierarchy -- for the execution workspace > set of templates -- for the execution workspace > nodes -- for the execution workspace > > I found we need two class hierarchies to prevent design destruction > because > classes are not constant. Classes, templates, nodes all have an > influence on > the execution behaviour in the execution workspace, and in the static > workspace if they have super powered functions. > A default set of classes/templates prepared by the system can be added > to the > classes/templates either for the static workspace or for the execution > workspace. > It's not what I had imagined first, but not bad I think. > (Hmmm, looks it may be contradictory to your idea reading the next part) You are right that we need two sets of (class, templates, nodes) for each workspace (static, execution). > > Basically I'm for the idea in general, especially about the alpha/beta > and 1.0 > release, but I'm a bit confused about category "break not". > > - When you release a class or a template (say A), A will be put in the > user's > Kerama system. > - When the user makes a project and uses A, A must be copied, otherwise > A will be shared among all projects that uses A, and changes to A done > in one > project will be reflected to all the other projects. > - A will be copied, so the copy will be saved to the project file, > otherwise > chages to A will be lost. > - When a project file is opened, we can check if updated version of A > exists, > but A may not be what it was when it was released, because the user > can remove > properties. So even if the interface of the patch object is the same > as the > interface of old released object, we can't expect it doesn't break > code. > > Is this right? If this is true, the object publisher need to define what > is the 'interface' of the object to release "break not" object, e.g. if > he > define that property 'a' is an interface, the user can't remove it. > (It may also be wrong) Say the user has A copied into his project. He doesn't change it and now there's an update available. The update knows how A looked before and sees that the A in the project looks exactly the asme. So A in the project is replaced with the new version. If the user would have modified A, then the update had seen that the A in the project was changed and thus it tells the user to manually update it. > It leads to the idea that we can make a node that represents menu, tree, > status bar, etc. We need to draw a line somewhere between the items shown > below with regard to what to implement. > > a) super powered node > b) super powered node that represents menu, tree, status bar... > c) super powered node that represents connections > d) super powered node that creates menu, tree, status bar controls... > e) super powered node that defines Kerama core system. > > d) is close to what I said 'run Kerama on Kerama'. > e) means we have a minimum execution system and every other things (not > only GUI and it's event handlers) run on the system. > > I'm for a), against c), not sure about b) and d), definitely against e) > since e) needs vast amount of additional concept work. I'd rather look at > Kerama run on my machine. Hmm, I'm not sure what's best herem but your choice seems to be reasonable. Running kerama on kerama is definately ineresting and probably a very good testbed. -Matthias From nitro at dr-code.org Wed Aug 31 09:33:07 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 08:56:52 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050810193817086.YFNK.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050809211528897.UDIA.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> <20050810193817086.YFNK.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: Am Thu, 11 Aug 2005 04:30:02 +0900 hat Koichi Tamura geschrieben: >> d) is close to what I said 'run Kerama on Kerama'. > > This is some more details I have in my head ... > > When Kerama is started, it can automatically runs a project and its > startpoint > can be specified by its argument. You specify a project that creates GUI. > > kerama -project="keramaGui.prj" > (kerama command itself doesn't create any GUI) Sounds good! > In the GUI project, the main wxPython frame is created, then menu, > statusbar, > and other windows, controls, ... > > http://hohehohe2.hp.infoseek.co.jp/kerama/guidiagram.jpg > > When keramaGUI started execution, after some initialization process, > a value is set to the trigger property mainGUI.create (mainGUI is a > groupnode). > > In the functions in the mainGUI node, wxPython main frame is created. > When it is done, any value is set to mainGUI.done, which is connected to > menuBar.create and statusBar.create that are trigger properties to create > correstpondent GUI components. > mainGUI and other GUI nodes also have event handler properties. They are > set value when GUI event is produced on the component. > > Idealy, keramaGui.prj will create another main GUI when it is loaded > from Kerama application that is already started, so that we can develop > Kerama GUI on Kerama. And it will be a main GUI if Kerama is started with > -project="keramaGui.prj". > > (Again idealy ) we can make any kind of application that works on Kerama > and that has GUI in this way. > > Finally we may even change the behavior of the GUI when we edit them. > When we drag a button in another Kerama window that is currently being > developed, we can change the position of the button. One might want to > make such generic GUI editor. Also sounds good! > We should have another toplevel execution workspace to hold the gui > diagram. Hmm, not sure what you mean here. Can you elaborate a bit? > If you are for the idea, my idea about development is, we first develop > Kerama without using this, i.e. every GUI is hardcoded. It is Kerama > 1.0. Then > we start making Kerama 2.0 which has this kind of dinamic GUI. We will > have > lots of things to be implemented, developing both Kerama itself and > KeramaGUI > that works on Kerama will be difficult. > > What do you think? I agree with you, let's make a kerama without kerama first :) And then move to 2.0. -Matthias From nitro at dr-code.org Wed Aug 31 09:38:36 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:02:20 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: Am Sat, 13 Aug 2005 04:57:33 +0900 hat Koichi Tamura geschrieben: > I drew a couple of charts. > > 1. > My Image of property namespace implementation is like this. > http://hohehohe2.hp.infoseek.co.jp/kerama/misc/namespaceimpl.jpg > (Not a UML. I don't know how I can draw classes in UML) > Arrows are references. Either direct reference or through > other objects such as ICU. I'm wondering if we can make the > namespace object for templates similary. > > What do you think? Hmm, templates seem to be like frozen nodes, so I think one could re-use exactly this scheme. Maybe I'm oversimplifying though. > 2. > Again about >> d) is close to what I said 'run Kerama on Kerama'. > http://hohehohe2.hp.infoseek.co.jp/kerama/konk/index-eng.html > I'm not for the idea of implementing it to the next version, > still it'll be good for brain execise :) My impression is that everything of it looks fine. I am not 100% sure that I get the meaning of kerama core (I have an idea what it might be and this would be ok, i just want to makes sure), so can you explain what you mean by Kerama core? -Matthias From nitro at dr-code.org Wed Aug 31 09:39:52 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:03:37 2005 Subject: [pangalactic-dev] several questions about Pan Galactic In-Reply-To: <20050813173616499.JJMV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050813173616499.JJMV.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > Matthias, > > Would you give me the version info of your wxoo and > BasicTypes/BasicProperty, wxWidgets, and Python? > > I tried to install wxoo and tested lots of combinations > from olds one to new ones, but still suffering from the nasty > version conflict. Could be aother reason but version conflict > is most likely... I downloaded wxoo and the rest, but needed to modify a few things to get it running. I've mailed the author some weeks back, but he didn't fix it apparently. I can send you my modified version of it if you want to. It can run the demo at least (with some little test by me). -Matthias From nitro at dr-code.org Wed Aug 31 09:43:18 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:07:02 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050814011026661.JVSH.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050814011026661.JVSH.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: Am Sun, 14 Aug 2005 10:02:03 +0900 hat Koichi Tamura geschrieben: > Matthias, > >> There's a barrel class >> which holds all data of a barrel in the game. For example there's a >> member >> called mesh and a member called weight. Now the user instantiates two of >> these barrel classes. The barrel template has set a 'default.meshfile' >> for >> the mesh member and a '1' for the weight member. Now the user chooses to >> override 'default.meshfile' in barrel instance A with >> 'bigroundbarrel.meshfile'. Instance A was created with the template >> deepcopy method, Instance B with the reference version. Now the user >> changes weight in Instance B to '2'. So the current situation is: >> >> template barrel : mesh = default.meshfile, weight = 1 >> Instance A (deepcopied): mesh = bigroundbarrel.meshfile, weight = 1 >> Instance B (referenced): mesh = default.meshfile, weight = 2 >> >> Now somebody changes the default value of mesh to >> 'standardbarrel.meshfile'. In instance A nothing would change since it >> was >> deepcopied. However, in instance B default.meshfile will be changed, but >> weight will still be set to '2' because it was overridden. > > Ummm. I may be still misunderstanding. > - Can we change the value of property 'mesh' in Instance B without > overriding the property? If we can, is value of 'mesh' property in > the template changed? You can change the mesh property in B, but it is not changed in the template. Changing mesh is the same like changing weight in the above example. > - Can we put the template in the diagram? Not directly, you drag the template over to the diagram and then a node gets created from it. Just my idea of it though, do you see this issue differently? > - Can we change the value of 'mesh' property of the template during > execution time? Hmm, good question. I think that this could be possible, but it might be complicated, what do you think? It's similar to those hidden connections. > If we can't change the value of 'mesh' without overriding it and we > can't put the template in the diagram, can we represent the > template - instance relationship with kerama class and node? Yes. -Matthias From nitro at dr-code.org Wed Aug 31 09:45:48 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:09:31 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050814060607858.KNZN.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> References: <20050812200549801.GVQU.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> <20050814060607858.KNZN.8089.t-mta1.odn.ne.jp@mta1.odn.ne.jp> Message-ID: > What do you think about the idea of a node having multiple groups? > http://hohehohe2.hp.infoseek.co.jp/kerama/misc/grouplayer.jpg > The groups can be represented like a layer. > I think if a class can also have groups like this and can be > inherited/overrided > by the subclasses/nodes so that we can mimic object composition. > For example, first we have a node (node A) which is mainly implemented > inside > its group. If we want to have two different nodes (node B, node C) which > functions are similar to node A, we can change node A to a class (say, > class A), > and we can make node B, C that are delived from class A. > Also if we can represent inheritance as overlapped layers, we can make > it very > intuitive. > > I have now two questions if Kerama has this feature: > > - Does a property come with a group, or a node? > - How can we implement a group. Maybe we will want to use Python > class-instance > namespace. Is it possible? > > I haven't been thinking about it a lot (just a few hours), so it may > have some problems especially associated with override. I think it's quite complicated and if the node inherits the groups properties, you actually have multiple inheritance which you said you wanted to avoid. I think the layers make it difficult to "read" a program, it's kinda a like seeing a program in 3D in one of those science fiction movies :) -Matthias From nitro at dr-code.org Wed Aug 31 09:52:21 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:16:06 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> References: <20050817135839566.DTWW.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Message-ID: > Hi, > > I'm thinking if we should have a node that deals with GUI > objects(node, connection, class, ...). > The node has GUI related properties and powered functions that > defines GUI behaviour of the correspondant object. > > My gedankenexperiment is like this: > > -We can define a node's gui behaviours in its powered functions. > -If we can do it, we want to define a connection's gui behavioiurs > in the same way. > -A connection doesn't have properties nor functions, so we need a > node for the connection GUI. > -We need another execution workspace for it to place the node. --- (A) > -If a connection has a node that deals with the connections's GUI > representation, > It's natural we have a node that deals with "a node's GUI > representation", i.e. > we separate a node's GUI representation from the node itself. > -If we have both "connection GUI" node and "node GUI" node, it's natural > we > put them in the same workspace (A). > > > Node (intrinsic one) itself has only a property which specifies > the type of the "GUI node", and when the node is to be edited > in the GUI, the Kerama system creates an appropriate GUI node for > the (intrinsic) node. A set of default GUI node is prepared in the > Kerama GUI system and can be added freely. > > > It has both pros and cons. > > Pros: > > - Connections, Classes can be customized easily. > - Can separate node intrinsic properties and it's GUI related properties. Seperating GUI from node itself is absolutely desirable. For example I want to edit a Shader from kerama which has its properties dictated from a python class. There should not be any gui properties in it after kerama edited it. > Cons: > > - Need another workspace. > - We want to edit the space (A), so we need a GUI to edit it, > it means we need yet another workspace. So we need two more workspaces > in > total. > - Not so simple. If a node has a powered function for its GUI in itself, > it'll be more intuitive. > - Kerama core will be a little bit complicated. > > What do you thing? Maybe we make the gui representation static? Then we don't need to have extra workspaces (if i see this correctly). Like you have a kind of dict which maps a GUI representation function to each kerama class. For example "barrel class" -> "drawstandardboxwithprops" or "shader class" -> "drawcirclewithout props". This works kinda like the visitor pattern and is completely outside of the node data itself, so you have gui seperated from node. -Matthias From nitro at dr-code.org Wed Aug 31 09:54:07 2005 From: nitro at dr-code.org (Nitro) Date: Wed Aug 31 09:17:50 2005 Subject: [pangalactic-dev] about GUI design In-Reply-To: <20050821170356511.OKL.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> References: <20050818192708609.QIWE.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> <20050821170356511.OKL.2961.t-mta2.odn.ne.jp@mta2.odn.ne.jp> Message-ID: Am Mon, 22 Aug 2005 01:55:28 +0900 hat Koichi Tamura geschrieben: >> I'm thinking if we should have a node that deals with GUI >> objects(node, connection, class, ...). >> The node has GUI related properties and powered functions that >> defines GUI behaviour of the correspondant object. > >> Cons: > >> - We want to edit the space (A), so we need a GUI to edit it, >> it means we need yet another workspace. So we need two more >> workspaces in >> total. > > Hmmm, it's not true. "GUI object" node can be edited using the GUI > itself. Hmm, true. In my last mail I thought that we'd need two mopre workspaces because design destruction again. > I hope I can release > "Kerama specification draft 0.81-alpha (under construction)" > next month. Cool! > I can't do any more job this month cause I'm going to Kerama!!!!!!!! Yaaaaaaaaaaaaaay!!!! -Matthias