- Pharo-dev - lists.pharo.org

[Pharo-project] Brainstorming further out (was Re: What is the future of GUI in Pharo?)

by GÃ¶ran Krampe

Hi all! <brainstorm> I think we should think about what is happening out there with the new explosion around two things: - Mobile apps - HTML5 IT is changing, people are using pads and phones more than computers in the very near future (or already). And HTML5 gives advanced capabilities to play on these devices without having to buy the whole technical eco system of them (on Android it is Dalvik and on iOS it is Objective-C more or less). HTML5 is enabling stuff like ThinVNC for example (just google it). Or endless mobile frameworks like Joapp.com etc. And then to top it off we have Google and it Nacl project (Native client) which is basically a "sandboxed x86 environment" if I grokked it correctly. I want to be able to develop systems in Pharo/Squeak that can reach people on all these devices - of basically two flavors: - Typical mobile apps using webtech. For many of us - for maximum reach and minimum "tie up" with any of these platforms I think the new web solutions are the way to go. - Graphical apps that look exactly like I want (think games). How do we enable this? One way could be to create a fast "Morphic player" layer in js utilizing HTML5 to talk back to a server side Squeak. Kinda like ThinVNC but tailored for Morphic? Or even more crazy, what if one could sit in the debugger in Pharo and "step into" code actually running inside the js engine in a browser, seamless debugging and somehow also seamless access to the objects on the js side? If someone here has seen how VW integrates with Gemstone (or perhaps GLASS does the same now) - it is very seamless. In that "crazy vision" one obviously starts thinking of two roads: 1. Create a "Smalltalk" on top of js that we can "tether with". JTalk perhaps? 2. Or perhaps it is even better to let js be js and instead make Muhammed (=Pharo) come to the mountain (=the huge js eco system). Thus we could create a low level tethering with Javascript and then make Pharo "Javascript aware" on many levels, like inspectors, debugger, browsers etc. ...hmmm, wow. Now that I am typing this the above #2 would be awesomely cool. ;) Another more "conventional" way to capture #1 above is of course to integrate Joapp or JQuery Mobile (Renggli already doing that I think) with Seaside. </brainstorm> regards, GÃ¶ran PS. Yes, this post didn't start with "I want to do X" but on the other hand I am just brainstorming here, I am not saying anyone should do *anything*. :)

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Igor Stasenko

On 25 March 2011 09:22, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > StÃ©phane Ducasse wrote: >> >> the key problem is that if people do not jump in the water and decide to >> do something then nothing will happen beside reporting what other cool >> communities are doing. >> > > I fully agree what you are saying here ... personally I find the Morphic > learning curve waaaaaay to steep ... then again it may just be me :) > Heh.. take any GUI framework.. you will have same effect. It is naturally steep, because it tends to be big and complex. Because domain is quite big, and lies in a crossing of graphics and even handling. > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404804.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

[Pharo-project] [ANN] Self-learning PocketCube Solver

by HwaJong Oh

Hi, I am working on PocketCube solver (project wiki page here: http://appdal.com/groups/36442/wiki/80aad/PocketCube_Solver_with_Pharo.html ) My latest version of this can generate classes that can recognize pattern of PocketCube. If there is a PocketCubePattern subclass that matches current PocketCube it gets used to solve it. If there is not, a new pattern subclass gets created on the fly, and continues to solve the PocketCube. Watch the demo video below. http://www.screencast.com/users/BaseballTeam/folders/Jing/media/d7db8f85-f8… Best Regards -- View this message in context: http://forum.world.st/ANN-Self-learning-PocketCube-Solver-tp3404815p3404815… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Geert Claes

StÃ©phane Ducasse wrote: > > the key problem is that if people do not jump in the water and decide to > do something then nothing will happen beside reporting what other cool > communities are doing. > I fully agree what you are saying here ... personally I find the Morphic learning curve waaaaaay to steep ... then again it may just be me :) -- View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404804.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] A step toward reducing complexity

by StÃ©phane Ducasse

We should rename it and fork it so that doru gets less conflicts Stef On Mar 25, 2011, at 9:08 AM, Tudor Girba wrote: > Thanks, Doug. This was on my to do list for a long time. > > Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo and integrate fixes there because then it will just get messy. I will integrate it in Glamour. > > If you want to evolve it in the context of Pharo, you should rename it an put it in a different package (this would probably make sense anyway). > > Cheers, > Doru > > > On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > >> Thanks. >> May be the windowActiveDropShadowStyle could be just added to the UITheme class? >> >> Open a bug entry and attach code or slice there so that >> - have a look >> - not forget to integrate the fix. >> >> Stef >> >>> Reduce the complexity of user interface themes >>> >>> In general, user interface themes should inherit directly from UITheme, not >>> from a chain of themes. When you have a chain of themes, you are stuck with >>> the intermediate themes, whether you need/use them or not. Consider >>> GLMUITheme. Currently it is under UIThemeWatery2, which is under >>> UIThemeWatery, which is under UITheme. >>> >>> Some characteristics inherited from the chain are missing, but in principal, >>> GLMUITheme can be moved directly under UITheme with just 3 changes. >>> >>> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >>> >>> UITheme subclass: #GLMUITheme >>> instanceVariableNames: 'windowActiveDropShadowStyle' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Glamour-Morphic-Theme' >>> >>> 2. Add a class method >>> >>> isAbstract >>> "Answer whether the receiver is considered to be abstract." >>> ^false >>> >>> 3. Add an instance method >>> >>> windowActiveDropShadowStyle: anObject >>> "Set the value of windowActiveDropShadowStyle" >>> windowActiveDropShadowStyle := anObject >>> >>> >>> Because GLMOrangeUITheme inherits these changes, it does not need >>> modification. >>> >>> >>> -- >>> View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > >

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

For example I took the soup package and I added comments and tests After a couple of days the package was cooler. And this can be done by a lot of people. Stef > > On Mar 24, 2011, at 10:30 PM, nullPointer wrote: > >> I donÂ´t understand something. The implementation of new widgets will based on >> SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? > > > From what I see and after the discussion with alain: > we should build new widget on Morphic and after port them to the new core he has in mind. > >> If I could create new widgets and new UI functionalities I must work with >> SimpleMorphic? > > Not really except if you start to clean SimpleMorphic and migrate other code there too. > >> Will be change some things for work with openGL or others or really all is >> based in classic morphic? > > We do not know. Right now we should get a new canvas. > > Now if you want to see this front moving faster, you should help us because you played a lot with the system > and you know more than most of us. >> >> Regards. >> >> -- >> View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

Geert the key problem is that if people do not jump in the water and decide to do something then nothing will happen beside reporting what other cool communities are doing. So of course been aware that technology YZ K has a cool stuff is important, but more important is to build our own. What I learned is that if every I do something then I make progress every single day. So if all of us would open our browser and produce a little something then everyday we would do a large progress. Stef > > StÃ©phane Ducasse wrote: >> >> ... >> We are rewriting from scratch the basic tools >> - Browser (Nautilus soon to be announced - with groups, package browsers, >> refactorings, may be plugin architecture) >> - Finder >> - TestRunner (soon) >> - MCBrowser >> ... >> > > Yes, it would be great if it were easier to create/modify/customize Pharo's > tools! When rewriting I hope this will include improving the usability and > intuitiveness to get non-Smalltalkers up-to-speed faster. > > ps. on a side note, has anyone seen Jens MÃ¶nig's javascript morphic in the > browser http://www.chirp.scratchr.org/blog > http://www.chirp.scratchr.org/blog great stuff, make sure to watch the demo > on his iPad! > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3404753.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 25, 2011

Re: [Pharo-project] A step toward reducing complexity

by DougEdmunds

Not my intention to fork it. It does pick up some characteristics from the chain, which I didn't explore. On 3/25/2011 1:09 AM, Tudor Girba [via Smalltalk] wrote: > Thanks, Doug. This was on my to do list for a long time. > > Just a note: GLMUITheme is part of Glamour. Please do not fork it in > Pharo and integrate fixes there because then it will just get messy. I > will integrate it in Glamour. > > If you want to evolve it in the context of Pharo, you should rename it > an put it in a different package (this would probably make sense anyway). > > Cheers, > Doru > > > On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > >> Thanks. >> May be the windowActiveDropShadowStyle could be just added to the > UITheme class? >> >> Open a bug entry and attach code or slice there so that >> - have a look >> - not forget to integrate the fix. >> >> Stef >> >>> Reduce the complexity of user interface themes >>> >>> In general, user interface themes should inherit directly from > UITheme, not >>> from a chain of themes. When you have a chain of themes, you are > stuck with >>> the intermediate themes, whether you need/use them or not. Consider >>> GLMUITheme. Currently it is under UIThemeWatery2, which is under >>> UIThemeWatery, which is under UITheme. >>> >>> Some characteristics inherited from the chain are missing, but in > principal, >>> GLMUITheme can be moved directly under UITheme with just 3 changes. >>> >>> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >>> >>> UITheme subclass: #GLMUITheme >>> instanceVariableNames: 'windowActiveDropShadowStyle' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Glamour-Morphic-Theme' >>> >>> 2. Add a class method >>> >>> isAbstract >>> "Answer whether the receiver is considered to be abstract." >>> ^false >>> >>> 3. Add an instance method >>> >>> windowActiveDropShadowStyle: anObject >>> "Set the value of windowActiveDropShadowStyle" >>> windowActiveDropShadowStyle := anObject >>> >>> >>> Because GLMOrangeUITheme inherits these changes, it does not need >>> modification. >>> >>> >>> -- >>> View this message in context: > http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… > <http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h…> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404765.h… > > To unsubscribe from A step toward reducing complexity, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > -- View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404773.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

On Mar 24, 2011, at 10:30 PM, nullPointer wrote: > I donÂ´t understand something. The implementation of new widgets will based on > SimpleMorphic, o really will be the base Morph is based in SimpleMorphic? >From what I see and after the discussion with alain: we should build new widget on Morphic and after port them to the new core he has in mind. > If I could create new widgets and new UI functionalities I must work with > SimpleMorphic? Not really except if you start to clean SimpleMorphic and migrate other code there too. > Will be change some things for work with openGL or others or really all is > based in classic morphic? We do not know. Right now we should get a new canvas. Now if you want to see this front moving faster, you should help us because you played a lot with the system and you know more than most of us. > > Regards. > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 25, 2011

Re: [Pharo-project] A step toward reducing complexity

by Tudor Girba

Thanks, Doug. This was on my to do list for a long time. Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo and integrate fixes there because then it will just get messy. I will integrate it in Glamour. If you want to evolve it in the context of Pharo, you should rename it an put it in a different package (this would probably make sense anyway). Cheers, Doru On 25 Mar 2011, at 08:44, StÃ©phane Ducasse wrote: > Thanks. > May be the windowActiveDropShadowStyle could be just added to the UITheme class? > > Open a bug entry and attach code or slice there so that > - have a look > - not forget to integrate the fix. > > Stef > >> Reduce the complexity of user interface themes >> >> In general, user interface themes should inherit directly from UITheme, not >> from a chain of themes. When you have a chain of themes, you are stuck with >> the intermediate themes, whether you need/use them or not. Consider >> GLMUITheme. Currently it is under UIThemeWatery2, which is under >> UIThemeWatery, which is under UITheme. >> >> Some characteristics inherited from the chain are missing, but in principal, >> GLMUITheme can be moved directly under UITheme with just 3 changes. >> >> 1. Add an instanceVariable 'windowActiveDropShadowStyle' >> >> UITheme subclass: #GLMUITheme >> instanceVariableNames: 'windowActiveDropShadowStyle' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Glamour-Morphic-Theme' >> >> 2. Add a class method >> >> isAbstract >> "Answer whether the receiver is considered to be abstract." >> ^false >> >> 3. Add an instance method >> >> windowActiveDropShadowStyle: anObject >> "Set the value of windowActiveDropShadowStyle" >> windowActiveDropShadowStyle := anObject >> >> >> Because GLMOrangeUITheme inherits these changes, it does not need >> modification. >> >> >> -- >> View this message in context: http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.h… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- www.tudorgirba.com "We are all great at making mistakes."

March 25, 2011