May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 15 May 2013 09:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> How did you loaded NBOpenGL? >> For 2.0/3.0 pharo image use >> (ConfigurationOfNBOpenGL project version: '2.0') load > > I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) > It would be a lot better to make > > ConfigurationOfNBOpenGL load. > unless you put a lot of complex logic behind that "load", it will never work. That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo. And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :) > work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. > > Esteban -- Best regards, Igor Stasenko.

May 16, 2013

Re: [Pharo-dev] dual screen

by Igor Stasenko

On 16 May 2013 23:19, Ralph Boland <rpboland(a)gmail.com> wrote: > A different topic here although a dual screen issue. > I recently got a second screen and use it to run Squeak but I assume > the same issues occur with Pharo. > > I want to run one image across both screens. > For some windows (e.g. Browsers) I have modified the code so that > when the window > is initially opened, if necessary, it moves to the left so as to avoid > showing up across > both screens. Other windows (e.g. Save and Quit Window) can still > open split between > the two screens. I will fix these someday and then release my code to Squeak. > Feel free to then port it to Pharo. > > One problem though is vm related. If I save and quit and then reopen my image > all the windows on the right screen only are lost. This is a major pain. > > Also, what happens with three screens? > I am willing to look into this if someone sends me the money for a > third screen. ;-) > :) The problem will be always there, as long as VM in control how/when/where to open windows instead of image. And if you think that the cost of your work to change VM (+image, of course) would cost around 1 modern display price (even if you pick the most fancy one ;) , then i consider it is quite cheap .. > Ralph Boland > > > > -- > It is impossible for a man to learn what he thinks he already knows. > -- Epictetus > -- Best regards, Igor Stasenko.

May 16, 2013

Re: [Pharo-dev] TxTextLayout

by Igor Stasenko

On 16 May 2013 22:32, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> >> >> On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hello. >> > >> > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> > >> >> I have a question concerning the new TxText layout. >> >> How hard is it support inline non-text nodes (aka inline morphs) in a >> >> text >> >> layout? >> >> >> > >> > Do you mean supporting "TxMorphSpan" objects from text model at text >> > layout >> > level? >> > I think it is is not hard. Main issue here is supporting such kind of >> > spans >> > at text model level. But I think it is not difficult too, >> > I should look at code to answer in detail (can't do it now). >> > >> > >> >> >> >> My dream is still to be able to drag and drop an "instance" from an >> >> inspector to a workspace and do some operations on it using standard >> >> smalltalk. >> > >> > >> > +1 >> > And I want drag and drop objects between inspectors and between >> > workspaces. >> > >> > >> >> The only difference here would be instead of using a variable or >> >> expression to get an instance of something I would have a >> >> textual/visual >> >> node directly representing an instance! >> >> >> > >> > I'm not understand it. >> > By dropping some object to workspace It can create named variable and >> > then >> > you can use it for scripting inside workspace. >> > But what you suggest here? Can you explan deeply? >> >> >> Indeed I am not very clear (as usual :). >> a) I want to have a morph representing an object >> b) I want to embed these morphs into text >> c) I want to interact with these morphs and the text >> >> Let's say [Set] is the morph representing a set and I have the following >> source code with this morph inside: >> >> [Set] includes: #a >> >> Then this would be equivalent to the following: >> >> Smalltalk at: #MySetInstance put Set new. >> >> MySetInstance includes: #a >> >> However [Set] is not just text but a real morph I can drag around, right >> click >> and get a decent, instance specific menu on... and so forth :) >> >> is that more clear? > > > Ok. Now I understand what you want. > > I look at code. > As I sad before. TxMorphSpan requires some changes in text model code and > layout code. > Now TxLayout is collection of TxLayoutLine's where TxLayoutLine is > collection of TxLayoutSpan's. And now TxLayoutSpan is interval of > TxCharacterSpan. So TxLayoutSpan know that it is layout of characters. It > has font. > One of the options to support TxMorphSpan layout is to introduce > TxLayoutMorphSpan and implement all required protocol. To hook up this > object during layout building you should implement something like: > > TxMorphSpan>>layoutContentsBy: aLayoutBuilder > aLayoutBuilder currentSpan: (TxLayoutMorphSpan on: self) > aLayoutBuilder completeSpan > > You see it is quite simple. > > Now I almost finich edit decorators stuff. (I have TxNoneEditDecorator, > TxMaskEditDecorator, TxInsertModeEditDecorator, TxSmartCharsEditDecorator). > And next my task will validation/filtering of input. I think it will require > text model changes, so I will think about morph span too. > And of couse if you again join to TxText development it will be perfect! You > and Igor started this project. > Be assured, i will get there (once i will finish my vacation and Athens path geometry functionality ;). I really appreciate of what you doing (and i know multiple people who can put +1 here) The fact that you joined the project by your own will, is what makes open-source development much more sustainable and powerful, comparing to "traditional" development behind closed doors. Because when you write code you don't like (because it's your job which pays your bills), you just in "get things done" mode, but when you self-motivated and really care about result (like in open-source development), the way you do is quite different, and results too, as a consequence. I would really like if Alain and you could join the effort to make new editor be ready for next Pharo release (so we can get rid of confusing and scary code). ;) > Best regards, > Denis -- Best regards, Igor Stasenko.

May 16, 2013

Re: [Pharo-dev] dual screen

by Ralph Boland

A different topic here although a dual screen issue. I recently got a second screen and use it to run Squeak but I assume the same issues occur with Pharo. I want to run one image across both screens. For some windows (e.g. Browsers) I have modified the code so that when the window is initially opened, if necessary, it moves to the left so as to avoid showing up across both screens. Other windows (e.g. Save and Quit Window) can still open split between the two screens. I will fix these someday and then release my code to Squeak. Feel free to then port it to Pharo. One problem though is vm related. If I save and quit and then reopen my image all the windows on the right screen only are lost. This is a major pain. Also, what happens with three screens? I am willing to look into this if someone sends me the money for a third screen. ;-) Ralph Boland -- It is impossible for a man to learn what he thinks he already knows. -- Epictetus

May 16, 2013

Re: [Pharo-dev] TxTextLayout

by Benjamin

If the workspace also support Morphic Text Inlining, then you could duplicate the variable morphic element, and reuse it later :) Ben On May 16, 2013, at 10:38 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/17 Igor Stasenko <siguctua(a)gmail.com> > On 16 May 2013 14:37, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. > >> > >> 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> > >> > >>> I have a question concerning the new TxText layout. > >>> How hard is it support inline non-text nodes (aka inline morphs) in a text > >>> layout? > >>> > >> > >> Do you mean supporting "TxMorphSpan" objects from text model at text layout > >> level? > >> I think it is is not hard. Main issue here is supporting such kind of spans > >> at text model level. But I think it is not difficult too, > >> I should look at code to answer in detail (can't do it now). > >> > >> > >>> > >>> My dream is still to be able to drag and drop an "instance" from an > >>> inspector to a workspace and do some operations on it using standard > >>> smalltalk. > >> > >> > >> +1 > >> And I want drag and drop objects between inspectors and between workspaces. > >> > >> > >>> The only difference here would be instead of using a variable or > >>> expression to get an instance of something I would have a textual/visual > >>> node directly representing an instance! > >>> > >> > >> I'm not understand it. > >> By dropping some object to workspace It can create named variable and then > >> you can use it for scripting inside workspace. > >> But what you suggest here? Can you explan deeply? > > > > > > Indeed I am not very clear (as usual :). > > a) I want to have a morph representing an object > > b) I want to embed these morphs into text > > c) I want to interact with these morphs and the text > > > > Let's say [Set] is the morph representing a set and I have the following > > source code with this morph inside: > > > > [Set] includes: #a > > > > Then this would be equivalent to the following: > > > > Smalltalk at: #MySetInstance put Set new. > > > > MySetInstance includes: #a > > > > However [Set] is not just text but a real morph I can drag around, right click > > and get a decent, instance specific menu on... and so forth :) > > > > is that more clear? > > Yes. That's probably the good reason why Object should have #asMorph protocol. > > Right now it is a bit far from your idea: > > Object>>asMorph > "Open a morph, as best one can, on the receiver" > > ^ self asStringMorph > > > P.S. but please do not use "Smalltalk at: put:" in examples, because > someone could take it literally :) > > P.P.S. since inspector lists objects in left-side pane, i think it > would be nice to be able to drag > item out of it and drop into workspace. The morph should keep a > reference to dragged object > and represent it as morph, embedded in text or not... and you don't > need to keep it somewhere else (e.g in globals). > > It should be one of the options. I personally prefer to drop object into workspace, put name for it and use it as usual workspace variable. > Really how you will use "morph reference" of object at multiple places of workspace? How you will refer to it at new expressions? > > > -- > Best regards, > Igor Stasenko. > >

May 16, 2013

Re: [Pharo-dev] TxTextLayout

by Denis Kudriashov

2013/5/17 Igor Stasenko <siguctua(a)gmail.com> > On 16 May 2013 14:37, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. > >> > >> 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> > >> > >>> I have a question concerning the new TxText layout. > >>> How hard is it support inline non-text nodes (aka inline morphs) in a > text > >>> layout? > >>> > >> > >> Do you mean supporting "TxMorphSpan" objects from text model at text > layout > >> level? > >> I think it is is not hard. Main issue here is supporting such kind of > spans > >> at text model level. But I think it is not difficult too, > >> I should look at code to answer in detail (can't do it now). > >> > >> > >>> > >>> My dream is still to be able to drag and drop an "instance" from an > >>> inspector to a workspace and do some operations on it using standard > >>> smalltalk. > >> > >> > >> +1 > >> And I want drag and drop objects between inspectors and between > workspaces. > >> > >> > >>> The only difference here would be instead of using a variable or > >>> expression to get an instance of something I would have a > textual/visual > >>> node directly representing an instance! > >>> > >> > >> I'm not understand it. > >> By dropping some object to workspace It can create named variable and > then > >> you can use it for scripting inside workspace. > >> But what you suggest here? Can you explan deeply? > > > > > > Indeed I am not very clear (as usual :). > > a) I want to have a morph representing an object > > b) I want to embed these morphs into text > > c) I want to interact with these morphs and the text > > > > Let's say [Set] is the morph representing a set and I have the following > > source code with this morph inside: > > > > [Set] includes: #a > > > > Then this would be equivalent to the following: > > > > Smalltalk at: #MySetInstance put Set new. > > > > MySetInstance includes: #a > > > > However [Set] is not just text but a real morph I can drag around, right > click > > and get a decent, instance specific menu on... and so forth :) > > > > is that more clear? > > Yes. That's probably the good reason why Object should have #asMorph > protocol. > > Right now it is a bit far from your idea: > > Object>>asMorph > "Open a morph, as best one can, on the receiver" > > ^ self asStringMorph > > > P.S. but please do not use "Smalltalk at: put:" in examples, because > someone could take it literally :) > > P.P.S. since inspector lists objects in left-side pane, i think it > would be nice to be able to drag > item out of it and drop into workspace. The morph should keep a > reference to dragged object > and represent it as morph, embedded in text or not... and you don't > need to keep it somewhere else (e.g in globals). > It should be one of the options. I personally prefer to drop object into workspace, put name for it and use it as usual workspace variable. Really how you will use "morph reference" of object at multiple places of workspace? How you will refer to it at new expressions? > > -- > Best regards, > Igor Stasenko. > >

May 16, 2013

Re: [Pharo-dev] TxTextLayout

by Denis Kudriashov

2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > > > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> > > > >> I have a question concerning the new TxText layout. > >> How hard is it support inline non-text nodes (aka inline morphs) in a > text > >> layout? > >> > > > > Do you mean supporting "TxMorphSpan" objects from text model at text > layout > > level? > > I think it is is not hard. Main issue here is supporting such kind of > spans > > at text model level. But I think it is not difficult too, > > I should look at code to answer in detail (can't do it now). > > > > > >> > >> My dream is still to be able to drag and drop an "instance" from an > >> inspector to a workspace and do some operations on it using standard > >> smalltalk. > > > > > > +1 > > And I want drag and drop objects between inspectors and between > workspaces. > > > > > >> The only difference here would be instead of using a variable or > >> expression to get an instance of something I would have a textual/visual > >> node directly representing an instance! > >> > > > > I'm not understand it. > > By dropping some object to workspace It can create named variable and > then > > you can use it for scripting inside workspace. > > But what you suggest here? Can you explan deeply? > > > Indeed I am not very clear (as usual :). > a) I want to have a morph representing an object > b) I want to embed these morphs into text > c) I want to interact with these morphs and the text > > Let's say [Set] is the morph representing a set and I have the following > source code with this morph inside: > > [Set] includes: #a > > Then this would be equivalent to the following: > > Smalltalk at: #MySetInstance put Set new. > > MySetInstance includes: #a > > However [Set] is not just text but a real morph I can drag around, right > click > and get a decent, instance specific menu on... and so forth :) > > is that more clear? > Ok. Now I understand what you want. I look at code. As I sad before. TxMorphSpan requires some changes in text model code and layout code. Now TxLayout is collection of TxLayoutLine's where TxLayoutLine is collection of TxLayoutSpan's. And now TxLayoutSpan is interval of TxCharacterSpan. So TxLayoutSpan know that it is layout of characters. It has font. One of the options to support TxMorphSpan layout is to introduce TxLayoutMorphSpan and implement all required protocol. To hook up this object during layout building you should implement something like: TxMorphSpan>>layoutContentsBy: aLayoutBuilder aLayoutBuilder currentSpan: (TxLayoutMorphSpan on: self) aLayoutBuilder completeSpan You see it is quite simple. Now I almost finich edit decorators stuff. (I have TxNoneEditDecorator, TxMaskEditDecorator, TxInsertModeEditDecorator, TxSmartCharsEditDecorator). And next my task will validation/filtering of input. I think it will require text model changes, so I will think about morph span too. And of couse if you again join to TxText development it will be perfect! You and Igor started this project. Best regards, Denis .

May 16, 2013

Re: [Pharo-dev] TxTextLayout

by Igor Stasenko

On 16 May 2013 14:37, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hello. >> >> 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> >>> I have a question concerning the new TxText layout. >>> How hard is it support inline non-text nodes (aka inline morphs) in a text >>> layout? >>> >> >> Do you mean supporting "TxMorphSpan" objects from text model at text layout >> level? >> I think it is is not hard. Main issue here is supporting such kind of spans >> at text model level. But I think it is not difficult too, >> I should look at code to answer in detail (can't do it now). >> >> >>> >>> My dream is still to be able to drag and drop an "instance" from an >>> inspector to a workspace and do some operations on it using standard >>> smalltalk. >> >> >> +1 >> And I want drag and drop objects between inspectors and between workspaces. >> >> >>> The only difference here would be instead of using a variable or >>> expression to get an instance of something I would have a textual/visual >>> node directly representing an instance! >>> >> >> I'm not understand it. >> By dropping some object to workspace It can create named variable and then >> you can use it for scripting inside workspace. >> But what you suggest here? Can you explan deeply? > > > Indeed I am not very clear (as usual :). > a) I want to have a morph representing an object > b) I want to embed these morphs into text > c) I want to interact with these morphs and the text > > Let's say [Set] is the morph representing a set and I have the following > source code with this morph inside: > > [Set] includes: #a > > Then this would be equivalent to the following: > > Smalltalk at: #MySetInstance put Set new. > > MySetInstance includes: #a > > However [Set] is not just text but a real morph I can drag around, right click > and get a decent, instance specific menu on... and so forth :) > > is that more clear? Yes. That's probably the good reason why Object should have #asMorph protocol. Right now it is a bit far from your idea: Object>>asMorph "Open a morph, as best one can, on the receiver" ^ self asStringMorph P.S. but please do not use "Smalltalk at: put:" in examples, because someone could take it literally :) P.P.S. since inspector lists objects in left-side pane, i think it would be nice to be able to drag item out of it and drop into workspace. The morph should keep a reference to dragged object and represent it as morph, embedded in text or not... and you don't need to keep it somewhere else (e.g in globals). -- Best regards, Igor Stasenko.

May 16, 2013

Re: [Pharo-dev] dual screen - was Re: vm fixes

by btc＠openinworld.com

disregard previous post, I've seen the other responses that answer this. I knew of the VM limitation, just optimistically *hoped* this was a workaround. Actually, ignoring this thread and perhaps responding to the original thread, could you describe a bit more what it does. Sorry I don't quite get its use case. cheers -ben btc(a)openinworld.com wrote: > If I have dual monitors, of course when the OS spans them into a single display, > then of course I can drag Pharo open across both monitors, but that is not > ideal. Alternatively, if Pharo could open two native-OS-windows, then I could > full-screen one on each monitor, which would be really cool. Recently there was > a discussion on a mail list that I now can't find, about someone evaluating > Pharo and that was a critical requirement to port an existing application. For > my purposes, I am thinking a fair way ahead to a SCADA platform when an > industrial plant operator has two or more screens dedicated to a graphical mimic > of each part of the operating plant, running from the one image. [1] has > another use case. > > [1] > http://stackoverflow.com/questions/13982018/pharo-squeak-environment-with-d… > > cheers -ben > > Benjamin wrote: > > I am afraid not to understand your question > > > > Ben > > > > On May 16, 2013, at 4:04 AM, btc(a)openInWorld.com wrote: > > > > > >> Could this be used make Pharo dual-screened ? If yes, what would be the limitations ? > >> > >> cheers -ben > >> > >> Benjamin wrote: > >> > >>> In the following picture, instead of doing the classical MessageBrowser new openWithSpec, and get a Morphic window inside the os window of Pharo > >>> > >>> I do > >>> MessageBrowser openWorldWithSpec > >>> And here the message browser window *is* the system window. > >>> Basically, it sticks the morph on the world, do some magic around, and voilÃ . > >>> The cool part is that the rest of the code do not change at all, and still it opens a the good size, the title is properly updated etc > >>> > >>> > >>> > >>> Ben > >>> > >>> On May 14, 2013, at 10:28 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > >>> > >>> > >>>> This sounds intriguing. Can you be more specific? :) > >>>> > >>>> Doru > >>>> > >>>> > >>>> On May 14, 2013, at 10:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com > <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote: > >>>> > >>>> > >>>>> Thank you :) > >>>>> > >>>>> This fix goes with pair with > >>>>> https://pharo.fogbugz.com/default.asp?10619 > >>>>> > >>>>> Thanks to Esteban, one can now deploy a Spec widget with the os window as >> window :) > >>>>> > >>>>> Ben > >>>>> > >>>>> On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >>>>> > >>>>> > >>>>>> thanks esteban! > >>>>>> > >>>>>> On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>>>>> > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I just pushed fix for a weird bug in cocoa cog vm. > >>>>>>> It was crashing image when resizing using DisplayScreen>>#hostWindowSize: >>>> but even worst, some times was crashing also when dragging a window >>>> outside the world screen... > >>>>>>> > >>>>>>> The fix is there, but you will need to wait until tomorrow to have it in >>>> zeroconf (because of weird mac jenkins slave permissions). > >>>>>>> > >>>>>>> This increases a bit more the VM stability, still not perfect, but we are >>>> getting closer :) > >>>>>>> > >>>>>>> Esteban > >>>>>>> > >>>>>> > >>>> -- > >>>> www.tudorgirba.com <http://www.tudorgirba.com> > >>>> > >>>> "Presenting is storytelling." > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > >

May 16, 2013

dual screen - was Re: vm fixes

by btc＠openinworld.com

May 16, 2013