CLFramework and Pharo
Locked
12
12
 
|
I've just noticed that "nullPointer" now recreated http://www.squeaksource.com/CLFramework again
and uploaded CLFramework-nullPointer.90.mcz This time the code has a BSD license. The page says "Failed attempt of visual UI builder for Pharo-Polymorph. Abbandoned. Only works in Pharo 1.0" From my point of view: 1. This sounds very negative and I dont understand what lead to this decision. Similar to the decision to delete the project on SqS midway. Especially since the previews looked really really good. Is it a time or other issue on nullpointer's side or did the community fail in support... 2. This looks to me as if the project will stop now with 1.0 and is not moved to 1.1. or 1.2 3. I dont understand why the license changed from MIT to BSD but that does not allow us to include the now released version 90 or further work in the MIT licensed pharo-dev. I expect a day in the life of Pharo where people will demand more support to build visual tools. So to create a UI Builder the community - either has to start from scratch then - or continue with the project as a fork based on an earlier version ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) Really sad. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Indeed what I really want to know:
- why is it considered as failed ? - what were the errors made ? - if we re-start from scratch, what we should *not* do ? - if we fork it, what should we trash / rewrite ?
It's sad because "nullPointer" must have gain a lot of experience doing this, even if he doesn't like the code he has written, bump on hard issues, .... nullpointer, the code is important, sharing your experience is *far* more important. Please, do so.
Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Wed, Jun 30, 2010 at 9:27 AM, Torsten Bergmann <[hidden email]> wrote: I've just noticed that "nullPointer" now recreated http://www.squeaksource.com/CLFramework again _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
> I've just noticed that "nullPointer" now recreated http://www.squeaksource.com/CLFramework again
> and uploaded CLFramework-nullPointer.90.mcz Cool! This is a great news. > This time the code has a BSD license. The page says "Failed attempt of visual UI builder > for Pharo-Polymorph. Abbandoned. Only works in Pharo 1.0" > > From my point of view: > > 1. This sounds very negative and I dont understand what lead to this decision. Me neither. > Similar to the decision to delete the project on SqS midway. > Especially since the previews looked really really good. > Is it a time or other issue on nullpointer's side or did the community > fail in support... No idea > 2. This looks to me as if the project will stop now with 1.0 and is > not moved to 1.1. or 1.2 But may be people can port it. > 3. I dont understand why the license changed from MIT to BSD but > that does not allow us to include the now released version 90 or further > work in the MIT licensed pharo-dev. BSD and MIT are compatible and I'm sure that we can ask the author to change it > I expect a day in the life of Pharo where people will demand more support to build > visual tools. So to create a UI Builder the community > > - either has to start from scratch then > - or continue with the project as a fork based on an earlier version > ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) Does it load in pharo1.1? > > Really sad. > > Bye > T. > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
In reply to this post by Torsten Bergmann
Regards >3. I dont understand why the license changed from MIT to BSD but >that does not allow us to include the now released version 90 or further > work in the MIT licensed pharo-dev. Don´t exists problem for change the license. What differences exists between one and other? >I expect a day in the life of Pharo where people will demand more support to build >visual tools. So to create a UI Builder the community >- either has to start from scratch then >- or continue with the project as a fork based on an earlier version > ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) I believe is best create another from scratch, but with WPF like model and XAML as UI definition language. That is for people with best knowledges. The current version is 90. The main difference is addition of grid control. PS. I´m wrong before and did send the answer directly your mail, excuse me. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
Hi Gerard,
>Don´t exists problem for change the license. What differences exists between >one and other? I dont understand. If you dont know the difference why did you change from MIT to BSD for CLFramework? I'm not a lawyer but AFAIK the MIT states more explicitly the rights given to the end-user. And there are many BSD versions "Modified BSD license", "The Clear BSD License", "FreeBSD license", ... MIT is what Pharo uses and accepts for inclusion. Keeping MIT for the framework would also help to reuse part of your code in Pharo itself or use the UI builder as part of special Pharo distributions. Maybe also there is a way that the project continues >I believe is best create another from scratch, but with WPF like model and >XAML as UI definition language. That is for people with best knowledges. That sounds like the project really stopped from your side. Sad since beside "Dr. Geo II" [1] it was another real and interesting use case for Polymorph and was/is a usable UI builder. Laurent wrote on [2] >nullpointer, the code is important, sharing your experience is *far* more >important. Please, do so. Yes that would be good to know about the reasons. We know that you were not satisfied with your own code - but who of us really is? >The main difference is addition of grid control. Better widgets for Polymorph are always a plus ... when you accept MIT and sent the agreement [3] to Stef it may not be lost and can be folded back to Polymorph and Pharo. Or someone may step up and continue with the whole project. Would be sad if all your efforts would be lost. Thanks T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/025543.html [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-June/028789.html [3] http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by gerard alis
On Jun 30, 2010, at 12:53 PM, nullPointer wrote: > > Regards > >> 3. I dont understand why the license changed from MIT to BSD but >> that does not allow us to include the now released version 90 or further >> work in the MIT licensed pharo-dev. > > > Don´t exists problem for change the license. What differences exists between one > and other? there are equivalent: moose is developed under BSD on top of Pharo MIT Now we prefer all the pharo code to be MIT. > I expect a day in the life of Pharo where people will demand more support > to build >> visual tools. So to create a UI Builder the community > >> - either has to start from scratch then >> - or continue with the project as a fork based on an earlier version >> ("CLFramework-nullPointer.70.mcz" was the last one released as MIT) > > > I believe is best create another from scratch, but with WPF like model and XAML > as UI definition language. That is for people with best knowledges. I'm not convinced that we cannot learn from your development. > > The current version is 90. The main difference is addition of grid control. > > PS. I´m wrong before and did send the answer directly your mail, excuse me. > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
> I dont understand. If you dont know the difference why did you change > from MIT to BSD for CLFramework? No idea. I don´t know the change but you has warning me. The license is already changed to MIT. > Yes that would be good to know about the reasons. We know that you > were not satisfied with your own code - but who of us really is? I believe the valid model for create a UIBUilder is implement something like WPF in paint technology ( use OpenGL for paint and have 3D elements ) and XAML build the UI in design time. I don´t have knowledges for implement that, and I don´t know if is possible implement something like that on Pharo-Smalltalk; but I believe that is needed for create something UIBuilder modern for Pharo-Smalltalk, and not based on old systems. But that task is for people with more knowledges. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
>> I believe is best create another from scratch, >> but with WPF like model and XAML >> as UI definition language. That is for people with best knowledges. > > I'm not convinced that we cannot learn from your development. Because is needed change the current exposition to something like that: http://www.youtube.com/watch?v=4-T-yF3tXCc&feature=related http://www.youtube.com/watch?v=RyO7v06xlWM&feature=related Forget for a moment that is from M$ XD The wonderful of that is the language for define the UI interface, XAML, where you can describe not only basic propertys of "morph" like colors or positions, but too animations, mouseOver effects, timers, movies... And you can use editors of XAML, external from environment, for create more rich UIs. The current UIBuilder is based on old mechanism for build views, and surely with a lot of errors. I believe that that is the best direction for something more new and correct. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Wed, Jun 30, 2010 at 3:55 PM, nullPointer <[hidden email]> wrote:
I don't think WPF/XAML/whatever is good or bad (indeed I don't care :). But I think there's lot of value in having UIBuilder with "old mechanism" *now*. Do you think we can easily get it out of experimental / alpha state ? Or is there design/architecture mistakes such as thinking of creating applications with it is harmful ?
For the future, something based on Morphic 3 isn't the right way ? Cheers, Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
If you are generating XML, perhaps that should be left
to SIXX?? The result should be very close to Dolphin's ViewComposer, which
is a very powerful tool. There are some traps to avoid with conversion of
the serializer's output, but I can hopefully advise on where those might
arise. It's unclear to me whether Dolphin's "recent" conversion to view
resources as source code is a bad idea or simply under-supported in the area of
conversion of existing view resources. Serializer output worked, with some
caveats of dependence on layout changes and limitations on browsing into view
resources, at least when they are in their dormant state. We are starting
with real closures, dodging a bullet that hurt Dolphin.
From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont Sent: Wednesday, June 30, 2010 9:15 AM To: [hidden email] Subject: Re: [Pharo-project] CLFramework and Pharo On Wed, Jun 30, 2010 at 3:55 PM, nullPointer <[hidden email]>
wrote:
I don't think WPF/XAML/whatever is good or bad (indeed I don't care :). But
I think there's lot of value in having UIBuilder with "old mechanism" *now*. Do
you think we can easily get it out of experimental / alpha state ? Or is there
design/architecture mistakes such as thinking of creating applications with it
is harmful ?
For the future, something based on Morphic 3 isn't the right way ?
Cheers,
Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by gerard alis
Gerardo I already told you that in the past. We do not need XAML.
in VW you have window spec and they are exactly the same without the need for XML <Button> <Button.Background> <SolidColorBrush Color="Blue"/> </Button.Background> <Button.Foreground> <SolidColorBrush Color="Red"/> </Button.Foreground> <Button.Content> This is a button </Button.Content> </Button> #(#{UI.ButtonSpec} #layout: #(#{Graphics.LayoutFrame} 25 0.35 30 0 90 0.35 53 0 ) #name: #newButton #model: #newPattern #label: #(#{Kernel.UserMessage} #key: #New #defaultString: 'New' #catalogID: #pdp) #defaultable: true ) in VW they use that since 1995 and this is working no need for XML. You get a spec object and then you interpret it to populate the builder canvas. Have a look at Builder design pattern because it is inspired from the UIBuilder class of Visualworks (or if this is not the case this is exactly the pattern application). Here is a more complex example of a spec. windowSpec "UIPainter new openOnClass: self andSelector: #windowSpec" <resource: #canvas> ^#(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #label: #(#{Kernel.UserMessage} #key: #ContextListPolicyEditor #defaultString: 'Context list policy editor' #catalogID: #pdp) #min: #(#{Core.Point} 528 401 ) #max: #(#{Core.Point} 1024 768 ) #bounds: #(#{Graphics.Rectangle} 592 427 1120 828 ) #flags: 4 #menu: #menuBar ) #component: #(#{UI.SpecCollection} #collection: #( #(#{UI.LabelSpec} #layout: #(#{UI.AlignmentOrigin} 0 0.175 5 0 0.5 0 ) #name: #PatternListLabel #label: #(#{Kernel.UserMessage} #key: #Patterns #defaultString: 'Patterns' #catalogID: #pdp) ) #(#{UI.SequenceViewSpec} #properties: #(#{UI.PropertyListDictionary} #dragOkSelector #wantToDrag: #dragEnterSelector #dragEnter: #dragOverSelector #dragOver: #dragStartSelector #doDrag: #dropSelector #drop: #dragExitSelector #dragLeave: ) #layout: #(#{Graphics.LayoutFrame} 2 0 30 0 0 0.35 -60 1 ) #name: #patternList #model: #patternList #menu: #menu #useModifierKeys: true #selectionType: #highlight ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 25 0.35 30 0 90 0.35 53 0 ) #name: #newButton #model: #newPattern #label: #(#{Kernel.UserMessage} #key: #New #defaultString: 'New' #catalogID: #pdp) #defaultable: true ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 115 0.35 30 0 180 0.35 53 0 ) #name: #removeButton #model: #removePattern #label: #(#{Kernel.UserMessage} #key: #Remove #defaultString: 'Remove' #catalogID: #pdp) #defaultable: true ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 13 0.35 105 0 -9 0.75 128 0 ) #name: #patternNameInput #model: #patternName ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} 8 0.75 105 0 87 0.75 128 0 ) #name: #colorButton #model: #selectColor #label: #(#{Kernel.UserMessage} #key: #PickColor #defaultString: 'Pick Color' #catalogID: #pdp) #defaultable: true ) #(#{UI.TextEditorSpec} #layout: #(#{Graphics.LayoutFrame} 13 0.35 160 0 -8 1 -155 1 ) #name: #TextEditor1 #model: #patternString #tabRequiresControl: true ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 13 0.35 85 0 ) #name: #Label1 #label: #(#{Kernel.UserMessage} #key: #Name #defaultString: 'Name' #catalogID: #pdp) ) #(#{UI.LabelSpec} #layout: #(#{UI.AlignmentOrigin} 0 0.675 137 0 0.5 0 ) #name: #Label3 #label: #(#{Kernel.UserMessage} #key: #PatternString #defaultString: 'Pattern String' #catalogID: #pdp) ) #(#{UI.GroupBoxSpec} #layout: #(#{Graphics.LayoutFrame} 6 0.35 65 0 -2 1 -145 1 ) #name: #GroupBox1 #label: #(#{Kernel.UserMessage} #key: #Pattern #defaultString: 'Pattern' #catalogID: #pdp) ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 12 0.35 -118 1 0 0.679924 -92 1 ) #name: #matchSelectorInputField #model: #matchSelector #type: #symbol ) #(#{UI.InputFieldSpec} #layout: #(#{Graphics.LayoutFrame} 6 0.68 -118 1 -8 1 -92 1 ) #name: #conversionSelectorInputField #model: #conversionSelector #type: #symbol ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 12 0.35 -137 1 ) #name: #Label4 #label: #(#{Kernel.UserMessage} #key: #MatchSelector #defaultString: 'Match Selector' #catalogID: #pdp) ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 6 0.68 -137 1 ) #name: #Label5 #label: #(#{Kernel.UserMessage} #key: #ConversionSelector #defaultString: 'Conversion Selector' #catalogID: #pdp) ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutSizedOrigin} -100 0.5 -33 1 80 23 ) #name: #okButton #model: #accept #label: #(#{Kernel.UserMessage} #key: #Ok #defaultString: 'Ok' #catalogID: #pdp) #defaultable: true ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutSizedOrigin} 20 0.5 -33 1 81 23 ) #name: #cancelButton #model: #cancel #label: #(#{Kernel.UserMessage} #key: #Cancel #defaultString: 'Cancel' #catalogID: #pdp) #defaultable: true ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutOrigin} 12 0.35 -82 1 ) #name: #Label2 #label: #(#{Kernel.UserMessage} #key: #DisplayAllLimit #defaultString: 'Display all limit' #catalogID: #pdp) ) #(#{UI.SpinButtonSpec} #layout: #(#{Graphics.LayoutFrame} 90 0.35 -83 1 150 0.35 -60 1 ) #name: #displayAllLimitField #model: #displayAllLimit #type: #number #formatString: '0' #low: 1 #high: 100 #interval: 1 ) #(#{UI.ActionButtonSpec} #layout: #(#{UI.AlignmentOrigin} -10 1 -10 1 1 1 ) #name: #HelpButton #model: #help #label: #(#{Kernel.UserMessage} #key: #Help #defaultString: 'Help' #catalogID: #pdp) #defaultable: true ) #(#{UI.DividerSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 -48 1 0 1 -44 1 ) #name: #Divider1 ) ) ) ) On Jun 30, 2010, at 3:35 PM, nullPointer wrote: > >> I dont understand. If you dont know the difference why did you change >> from MIT to BSD for CLFramework? > > No idea. I don´t know the change but you has warning me. The license is already > changed to MIT. > >> Yes that would be good to know about the reasons. We know that you >> were not satisfied with your own code - but who of us really is? > > I believe the valid model for create a UIBUilder is implement something like WPF > in paint technology ( use OpenGL for paint and have 3D elements ) and XAML build > the UI in design time. I don´t have knowledges for implement that, and I don´t > know if is possible implement something like that on Pharo-Smalltalk; but I > believe that is needed for create something UIBuilder modern for > Pharo-Smalltalk, and not based on old systems. But that task is for people with > more knowledges. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
My knowledge is limited, but XML seems more portable than code Smalltalk.
Exists external editor (UI Builders too) for generate code XAML. Then that code could be "file in" used in a image of Pharo-Smalltalk where a class could parse it and build the UI. The idea is use external tools like that... http://www.youtube.com/watch?v=kyrN_Ky3HWc&feature=PlayList&p=0DD1BED3F232BE7F&playnext_from=PL&index=0&playnext=1 Is a very sample tool, but exists anothers much more complete. Why re-create a new ui builder when exists another external always best? I need only the code for rebuild the UI, not all ui builder tool. I don´t know nothing of Seaside, but I understand than the mechanism for build the UI will be the same. The same XAML code could build a equivalent UI, but in that case for HTML explorer. Well, only is a idea, surely stupid XD PS- My name is Gerard, without last vowel. |
|
|
But you rely on XML.
Second the builder (ie generating the XML) is not the problem as far as I know. but more how to assemble the widget and make sure that the layout are kept or specified. Then how using an external tools can make sure that this tool got well the way layoutMorph and other works? Stef > My knowledge is limited, but XML seems more portable than code Smalltalk. I do not understand why we want portability. Please note that the VWspec are as portable as XML between Smalltalk they are just arrays ( probably we would get a problem for the UI.Node notation but this is not the problem. > Exists external editor (UI Builders too) for generate code XAML. Then that > code could be "file in" used in a image of Pharo-Smalltalk where a class > could parse it and build the UI. The idea is use external tools like that... > > http://www.youtube.com/watch?v=kyrN_Ky3HWc&feature=PlayList&p=0DD1BED3F232BE7F&playnext_from=PL&index=0&playnext=1 > > Is a very sample tool, but exists anothers much more complete. Why re-create > a new ui builder when exists another external always best? I need only the > code for rebuild the UI, not all ui builder tool. > > I don´t know nothing of Seaside, but I understand than the mechanism for > build the UI will be the same. The same XAML code could build a equivalent > UI, but in that case for HTML explorer. But this is exactly what is done in VW with windowsSpec you can get a builder (which builds the application UI) either for your desktop or for VWWave (long time ago before seaside even if less powerful). > Well, only is a idea, surely stupid XD > > PS- My name is Gerard, without last vowel. > > > -- > View this message in context: http://forum.world.st/CLFramework-and-Pharo-tp2273256p2274245.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
Message: 5
Date: Wed, 30 Jun 2010 23:50:24 +0200 Another place to see such an example is Smalltalk/X. I think they conformed to the VW Specs as well... Rob _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
>Then how using an external tools can make sure that this tool got well the way layoutMorph >and other works? A smalltalk object must be the responsible of that, in the image. In 2d don´t exists differences in layouts policy. I believe the problem is implement in Morphic the 3d effects I did see in some ui designs of WPF-XAML. A new set of controls is needed, I believe. Well, I don´t want to debate that problems; I already say before that is for Smalltalk gurús, not is only a new ui builder. Exists much more problems. Regards |
|
|
I do not see why 3d is different from 2d.
You get a spec and a builder and you generate the ui or the spec Now I hope somebody will take over what you did and focus on a good 2d one On Jul 1, 2010, at 9:25 AM, nullPointer wrote: > > >> Then how using an external tools can make sure that this tool got well the > way layoutMorph >> and other works? > > A smalltalk object must be the responsible of that, in the image. In 2d > don´t exists differences in layouts policy. I believe the problem is > implement in Morphic the 3d effects I did see in some ui designs of > WPF-XAML. A new set of controls is needed, I believe. > > Well, I don´t want to debate that problems; I already say before that is for > Smalltalk gurús, not is only a new ui builder. Exists much more problems. > > Regards > -- > View this message in context: http://forum.world.st/CLFramework-and-Pharo-tp2273256p2274707.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>I do not see why 3d is different from 2d.
>You get a spec and a builder and you generate the ui or the spec Well, I don´t know the state of 3d in Morphic. Really is possible move, rotate and more 3D effects in simple morphs? I don´t want say a OpenGL window, else 3d Morphs. I don´t know the state of that in Pharo-Smalltalk. >Now I hope somebody will take over what you did and focus on a good 2d one I be very much pessimist. I believe is needed change many things from "base". If somebody need help on any question or problem I don´t have any problem in help him. Regards |
|
|
> I do not see why 3d is different from 2d.
>> You get a spec and a builder and you generate the ui or the spec > > Well, I don´t know the state of 3d in Morphic. Really is possible move, > rotate and more 3D effects in simple morphs? I don´t want say a OpenGL > window, else 3d Morphs. I don´t know the state of that in Pharo-Smalltalk. but nobody care about 3D, on my mac I have no 3d widgets and this is perfect. > >> Now I hope somebody will take over what you did and focus on a good 2d one > > I be very much pessimist. I believe is needed change many things from > "base". If somebody need help on any question or problem I don´t have any > problem in help him. could you let people publish on the repository. I wanted to add a class ReadMeFirst with a comment to show how to open the builder. Stef > > Regards > -- > View this message in context: http://forum.world.st/CLFramework-and-Pharo-tp2273256p2274779.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>but nobody care about 3D, on my mac I have no 3d widgets and this is perfect. For multitouch applications is very important now, and much more in the future ...... >could you let people publish on the repository. >I wanted to add a class ReadMeFirst with a comment to show how to open the builder. If not is problem I will create a new project called UIBuilder, with the same code, opened for all. Regards |
Re: CLFramework and Pharo
|
|
On Jul 1, 2010, at 10:47 03AM, nullPointer wrote: > > >> but nobody care about 3D, on my mac I have no 3d widgets and this is > perfect. > > For multitouch applications is very important now, and much more in the > future ...... > >> could you let people publish on the repository. >> I wanted to add a class ReadMeFirst with a comment to show how to open the > builder. > > If not is problem I will create a new project called UIBuilder, with the > same code, opened for all. > > Regards I made some changes last night to make it work better in 1.1, would be nice to be able to commit those as well :) I really like the amount of class comments, editing the CLUIBuilderMainForm with a CLUIBuilderMainForm, and the use of Traits for defining common CL-widget capabilities. (Although the code which checks for use of those traits seems somewhat hairy... especially when withInheritanceTraitCompositionIncludes: has been removed... how about a simple usesTrait: selector or something?) Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |