A new GUI visual designer
Locked
1234
1234
 
|
Btw, why the use of qt's signals and slots and not Cocoas outlets?
|
Re: A new GUI visual designer
|
|
In reply to this post by Richard Durr-2
You cite an example very similar to what Dolphin does, and we could do with SIXX. Dolphin serializes things not to avoid the image but to allow packaging. SIXX could do the same for us. I favor the idea of SIXX more to avoid falling into a trap of being subliminally influenced by (aka stealing from) Window Builder than because I think it is the correct thing to do. If we had something that could read and rewrite Smalltalk code that is truly independent of WB, then class methods would be nice way to store GUI designs.
Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Richard Durr [[hidden email]] Sent: Sunday, February 13, 2011 11:56 AM To: [hidden email] Subject: Re: [Pharo-project] A new GUI visual designer Just a comment: :) The Interface Builder of Nextstep and Mac OS X – a closely Smalltalk-related and inspired system – creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened – not created) and then loaded into the object space of the app. This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. That is ironic, I think ^^ -- Sent from my DynaBook. |
|
|
In reply to this post by Richard Durr-2
Am 2011-02-13 um 17:58 schrieb Richard Durr:
> Btw, why the use of qt's signals and slots and not Cocoas outlets? > Because the author of the Morphic Builder has had more experience with qt and likes it. He hasn't done Mac programming until now, afaik. |
|
|
In reply to this post by Schwab,Wilhelm K
Hi!
Sorry, this post turned out long. But hopefully interesting anyway. On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote: > You cite an example very similar to what Dolphin does, and we could do with SIXX. > Dolphin serializes things not to avoid the image but to allow packaging. > SIXX could do the same for us. [SNIP] > If we had something that could read and rewrite Smalltalk code that is truly independent > of WB, then class methods would be nice way to store GUI designs. > > Bill Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years: - Build them with code each time we want them Pros: Resilient against framework/library changes Very readable and editable Easy to "store" in the language (just save as a method) Cons: Very hard to use as a "save format" Has too much freedom if we hand edit it I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb). - Save them in "dumb" data structures (like VW specs) Pros: A bit resilient since it relies on a builder, but not as good as code because it is just dumb data Similar easy to store in the language Cons: Not readable and editable VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right. - Save them in a more advanced (than an Array) non Smalltalk langauge like XML Pros: Quite resilient against framework/library changes, if grammar is made to be declarative in style Easy to use as "save format" Cons: Get's complex and icky Not so easy to "store" in language (a String literal?) Not so readable and editable IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there? - Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate Pros: Simple as save format, just smack it out Cons: Not resilient against framework/library changes, in fact very brittle Not readable nor editable Not so easy to "store" in langauge (ByteArray? String literal? Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :) Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: http://goran.krampe.se/blog/Squeak/Tirade.rdoc http://goran.krampe.se/blog/Squeak/Tirade2.rdoc http://goran.krampe.se/blog/Squeak/Tirade3.rdoc (sorry for lack of nice CSS there) NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. So, given the Pros/Cons above, let's see how Tirade would fit: * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: tiradeOn: recorder "Create Tirade by sending messages to a Tirade recorder." recorder message1; message2; message3 In that way you can still use senders/implementors etc of the message selectors. * Easy to store outside of the language: yes, trivial, and fast to write and read * Very resilient against framework/library changes if we use a declarative style. regards, Göran |
Administrator
|
I'll leave in the middle whether or not the "Morphic UI Designer" is the right solution for Pharo, but looking at the number of posts in this thread I do have a feeling that:
1. most do agree that a better way to create the user interface really is needed 2. there are strong opinions on how this UI designer should and/or should not be implemented As most applications require a UI, having a powerful UI builder is extremely important for any development environment to succeed. If Pharo were to have an intuitive UI builder, I think even more people would give Pharo a go and probably improve Pharo's existing development environment along the way. Göran just constructively summarized and grouped some groups and optiobs for the "how". So rather than arguing what "not" to do, let's try and focus on how it will be done and who is able to help. Having said all that, I think Smalltalk could benefit even more if Smalltalk had a powerful UI builder for web applications, but I guess that's outside Pharo's scope and is something the frameworks like AIDA, Seaside or Iliad need to address. |
Re: A new GUI visual designer
|
|
In reply to this post by Göran Krampe
Hi Göran,
On 14 Feb 2011, at 00:18, Göran Krampe wrote: > Hi! > > Sorry, this post turned out long. But hopefully interesting anyway. > > On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote: >> You cite an example very similar to what Dolphin does, and we could do with SIXX. > > Dolphin serializes things not to avoid the image but to allow packaging. > > SIXX could do the same for us. > [SNIP] > > > If we had something that could read and rewrite Smalltalk code that is truly independent > > of WB, then class methods would be nice way to store GUI designs. >> >> Bill > > Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years: > > - Build them with code each time we want them > Pros: Resilient against framework/library changes > Very readable and editable > Easy to "store" in the language (just save as a method) > Cons: Very hard to use as a "save format" > Has too much freedom if we hand edit it > > I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb). > > - Save them in "dumb" data structures (like VW specs) > Pros: A bit resilient since it relies on a builder, but not as good as code because it is just dumb data > Similar easy to store in the language > Cons: Not readable and editable > > VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right. > > > - Save them in a more advanced (than an Array) non Smalltalk langauge like XML > Pros: Quite resilient against framework/library changes, if grammar is made to be declarative in style > Easy to use as "save format" > Cons: Get's complex and icky > Not so easy to "store" in language (a String literal?) > Not so readable and editable > > IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there? > > > - Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate > Pros: Simple as save format, just smack it out > Cons: Not resilient against framework/library changes, in fact very brittle > Not readable nor editable > Not so easy to "store" in langauge (ByteArray? String literal? > > Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :) Excellent summary/writeup ! > Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: > > http://goran.krampe.se/blog/Squeak/Tirade.rdoc > http://goran.krampe.se/blog/Squeak/Tirade2.rdoc > http://goran.krampe.se/blog/Squeak/Tirade3.rdoc > > (sorry for lack of nice CSS there) > > NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. > > Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. > > Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. > > So, given the Pros/Cons above, let's see how Tirade would fit: > > * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. > > * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: > > tiradeOn: recorder > "Create Tirade by sending messages to a Tirade recorder." > recorder message1; message2; message3 > > In that way you can still use senders/implementors etc of the message selectors. > > * Easy to store outside of the language: yes, trivial, and fast to write and read > > * Very resilient against framework/library changes if we use a declarative style. Tirade looks cool, very nice idea, simple and powerful. Nice name too. Some questions: - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ? - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? - has this since 2009 been used anywhere ? - how about inter Smalltalk interoperability ? Sven |
|
|
On 14 February 2011 09:59, Sven Van Caekenberghe <[hidden email]> wrote:
> Hi Göran, > > On 14 Feb 2011, at 00:18, Göran Krampe wrote: > >> Hi! >> >> Sorry, this post turned out long. But hopefully interesting anyway. >> >> On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote: >>> You cite an example very similar to what Dolphin does, and we could do with SIXX. >> > Dolphin serializes things not to avoid the image but to allow packaging. >> > SIXX could do the same for us. >> [SNIP] >> >> > If we had something that could read and rewrite Smalltalk code that is truly independent >> > of WB, then class methods would be nice way to store GUI designs. >>> >>> Bill >> >> Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years: >> >> - Build them with code each time we want them >> Pros: Resilient against framework/library changes >> Very readable and editable >> Easy to "store" in the language (just save as a method) >> Cons: Very hard to use as a "save format" >> Has too much freedom if we hand edit it >> >> I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb). >> >> - Save them in "dumb" data structures (like VW specs) >> Pros: A bit resilient since it relies on a builder, but not as good as code because it is just dumb data >> Similar easy to store in the language >> Cons: Not readable and editable >> >> VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right. >> >> >> - Save them in a more advanced (than an Array) non Smalltalk langauge like XML >> Pros: Quite resilient against framework/library changes, if grammar is made to be declarative in style >> Easy to use as "save format" >> Cons: Get's complex and icky >> Not so easy to "store" in language (a String literal?) >> Not so readable and editable >> >> IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there? >> >> >> - Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate >> Pros: Simple as save format, just smack it out >> Cons: Not resilient against framework/library changes, in fact very brittle >> Not readable nor editable >> Not so easy to "store" in langauge (ByteArray? String literal? >> >> Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :) > > Excellent summary/writeup ! > >> Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: >> >> http://goran.krampe.se/blog/Squeak/Tirade.rdoc >> http://goran.krampe.se/blog/Squeak/Tirade2.rdoc >> http://goran.krampe.se/blog/Squeak/Tirade3.rdoc >> >> (sorry for lack of nice CSS there) >> >> NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. >> >> Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. >> >> Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. >> >> So, given the Pros/Cons above, let's see how Tirade would fit: >> >> * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. >> >> * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: >> >> tiradeOn: recorder >> "Create Tirade by sending messages to a Tirade recorder." >> recorder message1; message2; message3 >> >> In that way you can still use senders/implementors etc of the message selectors. >> >> * Easy to store outside of the language: yes, trivial, and fast to write and read >> >> * Very resilient against framework/library changes if we use a declarative style. > > Tirade looks cool, very nice idea, simple and powerful. Nice name too. > > Some questions: > > - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? > - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ? No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. Just don't use ascii, then you won't need to escape non-ascii characters. :) > - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? > - has this since 2009 been used anywhere ? > - how about inter Smalltalk interoperability ? > > Sven > > > -- Best regards, Igor Stasenko AKA sig. |
Re: A new GUI visual designer
|
|
On 14 Feb 2011, at 10:28, Igor Stasenko wrote: >> - there does not seem to be a way to deal with non-ascii strings like 'Göran', shouldn't there be something like JSON escapes ? > > No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. > Just don't use ascii, then you won't need to escape non-ascii characters. :) I know what UTF-8 encoding is and I know the date. However, then the Tirade spec should say, all data is encoded in UTF-8 by default, leaving it open like this is asking for problems. But even then, for a data interchange format I think that ASCII + enscaping is a better deal that will cause less problems. Sven |
|
|
In reply to this post by Göran Krampe
Hi Göran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547 |
Re: A new GUI visual designer
|
|
In reply to this post by Sven Van Caekenberghe
We are still talking about Tirade right? A Smalltalk-specific interchange format, built-in-20XX, with no existing consumers to worry about? I don't really think choosing UTF8 from the start will cause more problems for anyone, though I agree it should be an explicit fact. Cheers, Henry |
|
|
In reply to this post by Tobias Pape
Ah okay I thought this to be a deliberate design decision. I would advise then to adopt it right now.
On Sun, Feb 13, 2011 at 8:44 PM, Tobias Pape <[hidden email]> wrote: Am 2011-02-13 um 17:58 schrieb Richard Durr: |
|
|
not right now. argh!
On Mon, Feb 14, 2011 at 7:06 PM, Richard Durr <[hidden email]> wrote: Ah okay I thought this to be a deliberate design decision. I would advise then to adopt it right now. |
Re: A new GUI visual designer
|
|
In reply to this post by Richard Durr-2
What is happening if the class of your application UI gets a new variables or if a superclass changes its structure?
May be in objective-C you have to resave your nib? Stef > Just a comment: :) > > The Interface Builder of Nextstep and Mac OS X – a closely Smalltalk-related and inspired system – creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened – not created) and then loaded into the object space of the app. > > This reminds me of the way, the Smalltalk Image works – except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. > > But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. > > That is ironic, I think ^^ > > -- > Sent from my DynaBook. |
Re: A new GUI visual designer
|
|
In reply to this post by Richard Durr-2
do you have a pointer to cocoas outlets?
On Feb 13, 2011, at 5:58 PM, Richard Durr wrote: > Btw, why the use of qt's signals and slots and not Cocoas outlets? I could answer a lot of these questions if people pay us another engineer :) So at the end this is just a question of resource not vision. Stef |
Re: A new GUI visual designer
|
|
In reply to this post by Stéphane Ducasse
In Dolphin, one can cope with that fairly easily - most of the time. The trick is to change the affected class' serializing version number, which causes the loader to seek help reading old serialized data, which arrives as an array. Streams work well for adapting the old array into an array that is correct for the current version.
I have not used SIXX long enough to encounter this in a significant way. SIXX appears to depend on messages/apsects, where Dolphin's serializer deals directly in instance variables. My guess is that SIXX will be tolerant of changes that would clobber Dolphin's serializer, but that Dolphin provides tools to handle it. SIXX has something too; I have not needed it yet. One thing about SmartReferenceStream: the conversion methods go in the serializer itself; they belong in the affected class, or in its proxy if one is used. SmartReferenceStream also assumes that user==developer :( Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Monday, February 14, 2011 3:41 PM To: [hidden email] Subject: Re: [Pharo-project] A new GUI visual designer What is happening if the class of your application UI gets a new variables or if a superclass changes its structure? May be in objective-C you have to resave your nib? Stef DynaBook. |
|
|
In reply to this post by Geert Claes
I would like to add to this discussion the following:
1) Are we willing to create a Pharo only solution to a GUI designer? Or: 2) Can we think of a Smalltalk wide new solution which could be standard and flavour agnostic, so once a programmer learns to use it, its knowledge will be useful to any Smalltalk? 3) Do we fell we should lead the way inventing a new GUI design approach, or the ones in market suffice and nullPointer's view that the designer is a commodity which we should make use of as other thing we do in Pharo, so steering us to concentrate in a set of widgets which those mainstream GUI design expect? I think if we invest in answering these questions we could arrive quickly to a feasible plan. my 0.019999 -- Cesar Rabak Em 14/02/2011 06:10, Geert Claes < [hidden email] > escreveu: I'll leave in the middle whether or not the "Morphic UI Designer" is the right solution for Pharo, but looking at the number of posts in this thread I do have a feeling that: 1. most do agree that a better way to create the user interface really is needed 2. there are strong opinions on how this UI designer should and/or should not be implemented As most applications require a UI, having a powerful UI builder is extremely important for any development environment to succeed. If Pharo were to have an intuitive UI builder, I think even more people would give Pharo a go and probably improve Pharo's existing development environment along the way. Göran just constructively summarized and grouped some groups and optiobs for the "how". So rather than arguing what "not" to do, let's try and focus on how it will be done and who is able to help. Having said all that, I think Smalltalk could benefit even more if Smalltalk had a powerful UI builder for web applications, but I guess that's outside Pharo's scope and is something the frameworks like AIDA, Seaside or Iliad need to address. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3304566.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. |
|
|
In reply to this post by ccrraaiigg
Craig,
Fantastic wishlist! However, maybe because the synthetic nature of the proposal, I think I missed something: How can a "...a method be transferred to another live system." as per your "4." and "Represent the state of that GUI with an object" and even be "amenable to framework change" simultaneously? -- Cesar Rabak Em 14/02/2011 08:14, Craig Latta < [hidden email] > escreveu: Hi Göran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547 |
|
|
In reply to this post by Stéphane Ducasse
Here is more information:
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/IB_UserGuide/Introduction/Introduction.html
On Mon, Feb 14, 2011 at 9:41 PM, Stéphane Ducasse <[hidden email]> wrote: What is happening if the class of your application UI gets a new variables or if a superclass changes its structure? I do not know.
|
Re: A new GUI visual designer
|
|
|
|
I do not really like QT and would prefer somethink more mac like.
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |