What is the future of GUI in Pharo?
Locked
12
12
What is the future of GUI in Pharo?
 
|
Many new things is happens this days on Pharo, and I don´t understand the status of all.
What is the future of GUI in Pharo? what changes will happen? which is the roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works with another way of draw/render the morphs? We will reduce the number of morph classes and hierarchy? The Morphic UI designer will be incorporated in dev image? Thanks for your answers. |
Re: What is the future of GUI in Pharo?
|
Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools.
if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths Now if you want to see the system moving faster just join and help So here is a list Frameworks ---------- First step - Integrate polymorph (move class to the right packages, remove overrides) - Reduce complexity of morphic when possible In parallel - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) - Based on SimpleMorphic, clean also Morphic Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. Now he can fail too. so this is why the incremental points are important. Fixing and improving announcements is important - It was done during the last sprint - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. Widgets ------- We need better widgets - accordion - better text - grid We should evaluate your widgets to integrate them. But first we should clean what is there. Stacking on top of bad foundation just make the system more complex and difficult to maintain. Low level: a new Canvas and clean event ----------------------------------- Igor started to design a new canvas called Athens and we will see where it will go Again if people want to see this coming faster, they should help. The idea is to have a canvas for - opengl - cairo - bitbl We are evaluating the event hierarchy designed by Mickael Rueger and we would like to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph the idea is that event should be emitted by eventSensor not raw array I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore and so that all the vm are aligned. Tools ----- 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 - Debugger (waiting for a debugger model) The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it for the debugger but only for it. We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). Glamour will probably be used as a default super IDE of the future but it depends on people We are currently working on the fall back (the tools when you have nothing). So I hope it clarifies the picture and you are welcome to help. Now an important point This is not because something is under preparation that the other should not get clean and improve. We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed this is why we have this parallel strategy. Stef > Many new things is happens this days on Pharo, and I don´t understand the > status of all. > > What is the future of GUI in Pharo? what changes will happen? which is the > roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works > with another way of draw/render the morphs? > We will reduce the number of morph classes and hierarchy? The Morphic UI > designer will be incorporated in dev image? > > Thanks for your answers. |
Re: What is the future of GUI in Pharo?
|
|
Let me think a bit towards very far vision, don't be angry on me .. :)
Here it is: - a common UI for both Pharo and the web, by extending Morphic ideas to the web while things like CSS back to Morphic. - Morphic on top Jtalk for the web? The same API level one for Pharo too? - Isn't this like an extension, or better, towards the idea behind Lively? Janko On 24. 03. 2011 09:17, Stéphane Ducasse wrote: > Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools. > if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths > Now if you want to see the system moving faster just join and help > > So here is a list > > Frameworks > ---------- > First step > - Integrate polymorph (move class to the right packages, remove overrides) > - Reduce complexity of morphic when possible > > In parallel > - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) > - Based on SimpleMorphic, clean also Morphic > > Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side > or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. > Now he can fail too. so this is why the incremental points are important. > > Fixing and improving announcements is important > - It was done during the last sprint > - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. > - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. > > Widgets > ------- > We need better widgets > - accordion > - better text > - grid > We should evaluate your widgets to integrate them. But first we should clean what is there. > Stacking on top of bad foundation just make the system more complex and difficult to maintain. > > > Low level: a new Canvas and clean event > ----------------------------------- > Igor started to design a new canvas called Athens and we will see where it will go > Again if people want to see this coming faster, they should help. > The idea is to have a canvas for > - opengl > - cairo > - bitbl > > We are evaluating the event hierarchy designed by Mickael Rueger and we would like > to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph > the idea is that event should be emitted by eventSensor not raw array > > I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore > the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore > and so that all the vm are aligned. > > > Tools > ----- > 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 > - Debugger (waiting for a debugger model) > The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it > for the debugger but only for it. > > We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). > > Glamour will probably be used as a default super IDE of the future but it depends on people > We are currently working on the fall back (the tools when you have nothing). > > So I hope it clarifies the picture and you are welcome to help. Now an important point > This is not because something is under preparation that the other should not get clean and improve. > We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed > this is why we have this parallel strategy. > > > Stef > > > > > > > > >> Many new things is happens this days on Pharo, and I don´t understand the >> status of all. >> >> What is the future of GUI in Pharo? what changes will happen? which is the >> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works >> with another way of draw/render the morphs? >> We will reduce the number of morph classes and hierarchy? The Morphic UI >> designer will be incorporated in dev image? >> >> Thanks for your answers. > > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Stéphane Ducasse
Stef, put that on wiki, or somewhere else, so we can read it later :)
I like Grand Plans.. especially if they are succeed :) On 24 March 2011 09:17, Stéphane Ducasse <[hidden email]> wrote: > Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools. > if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths > Now if you want to see the system moving faster just join and help > > So here is a list > > Frameworks > ---------- > First step > - Integrate polymorph (move class to the right packages, remove overrides) > - Reduce complexity of morphic when possible > > In parallel > - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) > - Based on SimpleMorphic, clean also Morphic > > Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side > or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. > Now he can fail too. so this is why the incremental points are important. > > Fixing and improving announcements is important > - It was done during the last sprint > - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. > - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. > > Widgets > ------- > We need better widgets > - accordion > - better text > - grid > We should evaluate your widgets to integrate them. But first we should clean what is there. > Stacking on top of bad foundation just make the system more complex and difficult to maintain. > > > Low level: a new Canvas and clean event > ----------------------------------- > Igor started to design a new canvas called Athens and we will see where it will go > Again if people want to see this coming faster, they should help. > The idea is to have a canvas for > - opengl > - cairo > - bitbl > > We are evaluating the event hierarchy designed by Mickael Rueger and we would like > to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph > the idea is that event should be emitted by eventSensor not raw array > > I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore > the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore > and so that all the vm are aligned. > > > Tools > ----- > 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 > - Debugger (waiting for a debugger model) > The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it > for the debugger but only for it. > > We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). > > Glamour will probably be used as a default super IDE of the future but it depends on people > We are currently working on the fall back (the tools when you have nothing). > > So I hope it clarifies the picture and you are welcome to help. Now an important point > This is not because something is under preparation that the other should not get clean and improve. > We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed > this is why we have this parallel strategy. > > > Stef > > > > > > > > >> Many new things is happens this days on Pharo, and I don´t understand the >> status of all. >> >> What is the future of GUI in Pharo? what changes will happen? which is the >> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works >> with another way of draw/render the morphs? >> We will reduce the number of morph classes and hierarchy? The Morphic UI >> designer will be incorporated in dev image? >> >> Thanks for your answers. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: What is the future of GUI in Pharo?
|
|
Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, etc.
2011/3/24 Igor Stasenko <[hidden email]> Stef, put that on wiki, or somewhere else, so we can read it later :) -- Dennis Schetinin |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Janko Mivšek
On 2011-03-24, at 15:00, Janko Mivšek wrote: > Let me think a bit towards very far vision, don't be angry on me .. :) > Here it is: > > - a common UI for both Pharo and the web, by extending Morphic ideas > to the web while things like CSS back to Morphic. that would be called Glamour and works already > - Morphic on top Jtalk for the web? The same API level one for Pharo > too? > - Isn't this like an extension, or better, towards the idea > behind Lively? > > Janko > > On 24. 03. 2011 09:17, Stéphane Ducasse wrote: >> Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools. >> if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths >> Now if you want to see the system moving faster just join and help >> >> So here is a list >> >> Frameworks >> ---------- >> First step >> - Integrate polymorph (move class to the right packages, remove overrides) >> - Reduce complexity of morphic when possible >> >> In parallel >> - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) >> - Based on SimpleMorphic, clean also Morphic >> >> Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side >> or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. >> Now he can fail too. so this is why the incremental points are important. >> >> Fixing and improving announcements is important >> - It was done during the last sprint >> - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. >> - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. >> >> Widgets >> ------- >> We need better widgets >> - accordion >> - better text >> - grid >> We should evaluate your widgets to integrate them. But first we should clean what is there. >> Stacking on top of bad foundation just make the system more complex and difficult to maintain. >> >> >> Low level: a new Canvas and clean event >> ----------------------------------- >> Igor started to design a new canvas called Athens and we will see where it will go >> Again if people want to see this coming faster, they should help. >> The idea is to have a canvas for >> - opengl >> - cairo >> - bitbl >> >> We are evaluating the event hierarchy designed by Mickael Rueger and we would like >> to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph >> the idea is that event should be emitted by eventSensor not raw array >> >> I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore >> the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore >> and so that all the vm are aligned. >> >> >> Tools >> ----- >> 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 >> - Debugger (waiting for a debugger model) >> The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it >> for the debugger but only for it. >> >> We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). >> >> Glamour will probably be used as a default super IDE of the future but it depends on people >> We are currently working on the fall back (the tools when you have nothing). >> >> So I hope it clarifies the picture and you are welcome to help. Now an important point >> This is not because something is under preparation that the other should not get clean and improve. >> We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed >> this is why we have this parallel strategy. >> >> >> Stef >> >> >> >> >> >> >> >> >>> Many new things is happens this days on Pharo, and I don´t understand the >>> status of all. >>> >>> What is the future of GUI in Pharo? what changes will happen? which is the >>> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works >>> with another way of draw/render the morphs? >>> We will reduce the number of morph classes and hierarchy? The Morphic UI >>> designer will be incorporated in dev image? >>> >>> Thanks for your answers. >> >> >> > > -- > Janko Mivšek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Stéphane Ducasse
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?
If I could create new widgets and new UI functionalities I must work with SimpleMorphic? Will be change some things for work with openGL or others or really all is based in classic morphic? Regards. |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Stéphane Ducasse
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?
If I could create new widgets and new UI functionalities I must work with SimpleMorphic? Will be change some things for work with openGL or others or really all is based in classic morphic? Regards. |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by gerard alis
Hi nullPointer & all
New widgets are built with Morphic. Morphic is the current UI framework for Pharo and it is important to improve it. SimpleMorphic is not well integrated and is far from be usable. the goal would be to build a new framework from it by cleaning it, by integrating polymorph into it and by migrating the new cool widgets of Benjamin and others into it. As Stephane said, I'm willing to dig into it. but it is not sure at all it is feasible, that I will succeed, that it will be a good solution... and currently I'm too busy and I try to not open pharo too often :( about opengl, i don't know, a good canvas is certainly the key. cheers Alain Le 24/03/2011 22:30, nullPointer a écrit : > 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? > > If I could create new widgets and new UI functionalities I must work with > SimpleMorphic? > Will be change some things for work with openGL or others or really all is > based in classic morphic? > > Regards. > > -- > View this message in context: http://forum.world.st/What-is-the-future-of-GUI-in-Pharo-tp3400855p3403869.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > |
Re: What is the future of GUI in Pharo?
Administrator
|
In reply to this post by Stéphane Ducasse
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 great stuff, make sure to watch the demo on his iPad! |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by gerard alis
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.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Geert Claes
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.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post 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.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > |
Re: What is the future of GUI in Pharo?
|
Administrator
|
In reply to this post by Stéphane Ducasse
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 :) |
Re: What is the future of GUI in Pharo?
|
|
On 25 March 2011 09:22, Geert Claes <[hidden email]> 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 :) > 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.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig. |
Brainstorming further out (was Re: What is the future of GUI in Pharo?)
|
|
In reply to this post by Camillo Bruni
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*. :) |
Re: Brainstorming further out (was Re: What is the future of GUI in Pharo?)
|
|
A good post on the subject of Javascript remote debugging:
http://www.em-motion.mobi/2010/10/12/on-device-javascript-debugging-intro/ regards, Göran |
Re: Brainstorming further out (was Re: What is the future of GUI in Pharo?)
|
|
In reply to this post by Göran Krampe
Yep, most of what you described on HTML5 and Mobile front is already
there or in planning/vision state in Aida land, together with Jtalk. I'm just preparing a "On the web frontiers.." submittion for ESUG talk about this, so guys please keep comming out with such ideas! Janko On 25. 03. 2011 09:37, Göran Krampe wrote: > 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*. :) > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
Re: What is the future of GUI in Pharo?
|
|
In reply to this post by Dennis Schetinin
On Thu, Mar 24, 2011 at 4:33 PM, Dennis Schetinin <[hidden email]> wrote: Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, etc.
|
Re: What is the future of GUI in Pharo?
|
|
On 25 March 2011 12:12, Mariano Martinez Peck <[hidden email]> wrote:
> > > On Thu, Mar 24, 2011 at 4:33 PM, Dennis Schetinin <[hidden email]> wrote: >> >> Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, >> etc. > > http://code.google.com/p/pharo/wiki/IdeasToImplement > > but I guess it is quite outdated > Yes. But it would be nice to annotate this page and see and compare where we are now. >> >> 2011/3/24 Igor Stasenko <[hidden email]> >>> >>> Stef, put that on wiki, or somewhere else, so we can read it later :) >>> >>> I like Grand Plans.. especially if they are succeed :) >>> >>> On 24 March 2011 09:17, Stéphane Ducasse <[hidden email]> >>> wrote: >>> > Here is the vision: we need it better and simpler with better widgets, >>> > better UIBuilder and better tools. >>> > if you give me some engineers I can build something clear, now this is >>> > not the case so we are exploring and multiple paths >>> > Now if you want to see the system moving faster just join and help >>> > >>> > So here is a list >>> > >>> > Frameworks >>> > ---------- >>> > First step >>> > - Integrate polymorph (move class to the right packages, remove >>> > overrides) >>> > - Reduce complexity of morphic when possible >>> > >>> > In parallel >>> > - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) >>> > - Based on SimpleMorphic, clean also Morphic >>> > >>> > Alain told me that he want to take simpleMorphic and create a kernel >>> > that can be run and debugged on the side >>> > or morphic. Then he wants to add list and tree and see if he can add a >>> > better version of polymorph. >>> > Now he can fail too. so this is why the incremental points are >>> > important. >>> > >>> > Fixing and improving announcements is important >>> > - It was done during the last sprint >>> > - We were discussing how to make anonucement faster to avoid to >>> > climbing their parent tree - but no success so far. >>> > - We evaluated signals (as used in HPI frameworks) and we do >>> > not really like it. The use of thisContext is probably a problem among >>> > others. >>> > >>> > Widgets >>> > ------- >>> > We need better widgets >>> > - accordion >>> > - better text >>> > - grid >>> > We should evaluate your widgets to integrate them. But first we >>> > should clean what is there. >>> > Stacking on top of bad foundation just make the system more >>> > complex and difficult to maintain. >>> > >>> > >>> > Low level: a new Canvas and clean event >>> > ----------------------------------- >>> > Igor started to design a new canvas called Athens and we will >>> > see where it will go >>> > Again if people want to see this coming faster, they should >>> > help. >>> > The idea is to have a canvas for >>> > - opengl >>> > - cairo >>> > - bitbl >>> > >>> > We are evaluating the event hierarchy designed by Mickael Rueger >>> > and we would like >>> > to integrate it: eliminate the floating of arrays btween >>> > eventfetcher and HandMorph >>> > the idea is that event should be emitted by eventSensor not raw >>> > array >>> > >>> > I'm starting to clean Sensor references that are using the >>> > polling behavior because we should not have polling anymore >>> > the Windows virtual machine should be fixed and get the >>> > enhancement that Igor sent more than a year ago for the input semaphore >>> > and so that all the vm are aligned. >>> > >>> > >>> > Tools >>> > ----- >>> > 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 >>> > - Debugger (waiting for a debugger model) >>> > The idea is that we want to kill the StringHolder hierarchy >>> > alltogther so in a first phase we will probably have to keep it >>> > for the debugger but only for it. >>> > >>> > We will remove toolBuilder (we are waiting to finish the >>> > TestRunner rewriting). >>> > >>> > Glamour will probably be used as a default super IDE of the >>> > future but it depends on people >>> > We are currently working on the fall back (the tools when you >>> > have nothing). >>> > >>> > So I hope it clarifies the picture and you are welcome to help. Now an >>> > important point >>> > This is not because something is under preparation that the other >>> > should not get clean and improve. >>> > We have no problem throwing away our effort if something better come up >>> > but we should be prepared that nothing come up or is delayed >>> > this is why we have this parallel strategy. >>> > >>> > >>> > Stef >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >> Many new things is happens this days on Pharo, and I don´t understand >>> >> the >>> >> status of all. >>> >> >>> >> What is the future of GUI in Pharo? what changes will happen? which is >>> >> the >>> >> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will >>> >> works >>> >> with another way of draw/render the morphs? >>> >> We will reduce the number of morph classes and hierarchy? The Morphic >>> >> UI >>> >> designer will be incorporated in dev image? >>> >> >>> >> Thanks for your answers. >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Dennis Schetinin > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |