October 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo on retina display

by Tudor Girba

Hi, Athens would indeed be great. And I am happy that this investment has high priority in the team. But, I think for the usages that I see, we would need font support. Is there any progress on this front? Cheers, Doru On Fri, Oct 12, 2012 at 1:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 October 2012 11:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > also, the "retina problem" is a much more complex problem than it looks: > it exposes how aged (obsolete is a better word, I think) is our graphics > system. Now, Athens will solve that problem, but there is no magic to do > that can make the old graphics infrastructure to work with new hardware > requirements, any adaptation of it will take a lot of work, and probably > will not reach a good place... > > So, IMO the way to go is continue the efforts for make Athens work, and > move morphic to work with it as soon as possible. > > > > Yes, best thing for retina displays is to use Athens. It is maybe not > yet ready for prime time, but of course it is more than nothing, and i > crawling slowly to finish line :) > > I can only say that it was right strategic choice to put effort in > developing it. > Because if we wouldn't make such choice few years ago, and allocate > our resources to other tasks (and there's plenty), > there would be nothing to propose at all to support new generation of > hardware which comes these days. :) > > > Esteban > > > > ps: what? are you saying that we should remove something that is there > since 1980? Yes I am! :) > > > > > > On Oct 12, 2012, at 10:48 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > >> Sorry but we are a tiny team and we cannot run after everything at the > same time. We should get focused > >> and release something. Igor is already fixing the VM plugin, library > loading to avoid to have two libraries > >> of a given plugin and all the conflicts going together. > >> And we do not have retina mac right now. > >> > >> Stef > >> > >> > >>> :( > >>> > >>> On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris < > sean(a)clipperadams.com> wrote: > >>> Tudor Girba-2 wrote > >>>> Did anyone find a solution to this problem? > >>> > >>> I just got used to the fuzziness :) > >>> > >>> > >>> > >>> -- > >>> View this message in context: > http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >> > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Tudor Girba

Do not be defensive, please :). I simply expressed a feeling. You should definitely focus on releasing. Doru On Fri, Oct 12, 2012 at 10:48 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Sorry but we are a tiny team and we cannot run after everything at the > same time. We should get focused > and release something. Igor is already fixing the VM plugin, library > loading to avoid to have two libraries > of a given plugin and all the conflicts going together. > And we do not have retina mac right now. > > Stef > > > > :( > > > > On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Tudor Girba-2 wrote > > > Did anyone find a solution to this problem? > > > > I just got used to the fuzziness :) > > > > > > > > -- > > View this message in context: > http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Henrik Sperre Johansen

On 12.10.2012 11:06, Esteban Lorenzano wrote: > also, the "retina problem" is a much more complex problem than it looks: it exposes how aged (obsolete is a better word, I think) is our graphics system. Now, Athens will solve that problem, but there is no magic to do that can make the old graphics infrastructure to work with new hardware requirements, any adaptation of it will take a lot of work, and probably will not reach a good place... > So, IMO the way to go is continue the efforts for make Athens work, and move morphic to work with it as soon as possible. > > Esteban > > ps: what? are you saying that we should remove something that is there since 1980? Yes I am! :) I think, if not ideal, it could at least reach an interesting place if some consessions were to be made. - Giving up the World bitmap as a canonical bit-identical rendering on all platforms, and treat it more as a convenient place to grab contents for screenshots once in a while. In that case, what would need to be replaced if one were to use morphs mostly unaltered, is a way to fetch the current contents of a region of the screen buffer during a display cycle (for doing alpha blending in-image). Basically, instead of going graphic primitives -> paint on World bitmap -> display World bitmap onscreen you could then do graphic primitives -> paint on platform structures -> display platform structures onscreen -> synchronize World bitmap with platform structures and achieve pretty good consistency image-side with what is available today. IIRC, Athens goes Athens graphics primitives -> paint on backend structures (f.ex. Cairo) -> copy backend structures to World bitmap -> display World bitmap onscreen So the underlying way of how to actually display shapes onscreen hasn't changed much (at least the last time I looked at it), it still displays a bitmap, and that's it. Cheers, Henry

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Igor Stasenko

On 12 October 2012 11:06, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > also, the "retina problem" is a much more complex problem than it looks: it exposes how aged (obsolete is a better word, I think) is our graphics system. Now, Athens will solve that problem, but there is no magic to do that can make the old graphics infrastructure to work with new hardware requirements, any adaptation of it will take a lot of work, and probably will not reach a good place... > So, IMO the way to go is continue the efforts for make Athens work, and move morphic to work with it as soon as possible. > Yes, best thing for retina displays is to use Athens. It is maybe not yet ready for prime time, but of course it is more than nothing, and i crawling slowly to finish line :) I can only say that it was right strategic choice to put effort in developing it. Because if we wouldn't make such choice few years ago, and allocate our resources to other tasks (and there's plenty), there would be nothing to propose at all to support new generation of hardware which comes these days. :) > Esteban > > ps: what? are you saying that we should remove something that is there since 1980? Yes I am! :) > > > On Oct 12, 2012, at 10:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Sorry but we are a tiny team and we cannot run after everything at the same time. We should get focused >> and release something. Igor is already fixing the VM plugin, library loading to avoid to have two libraries >> of a given plugin and all the conflicts going together. >> And we do not have retina mac right now. >> >> Stef >> >> >>> :( >>> >>> On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> Tudor Girba-2 wrote >>>> Did anyone find a solution to this problem? >>> >>> I just got used to the fuzziness :) >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > -- Best regards, Igor Stasenko.

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by Stephan Eggermont

Igor wrote: >Anyways, UI stuff is tend to be complex no matter how nicely you wrap >it.. because it is UI. I'd have to disagree there. Building UIs with Glamour is easy. I'd say Spec is simply at too low an abstraction level for most UI work. We might need a different abstraction for different kind of applications (non-browsers, something like hotdraw comes to mind), but Glamour provides a very good base for most of the tools in the Pharo image. Stephan

Oct. 12, 2012

[Pharo-project] PhobosDemo problem on MACBook

by Dario Trussardi

Hi, i download the : PhobosDemo.app.tar.bz2 on a MAC . When i open the application the system open: the a Pharo app.image and the Phobos Demo window. Now when resizing the Pharo window the content is lost and inrecuperabile. Some idea? Thanks, Dario

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by Esteban Lorenzano

also, the "retina problem" is a much more complex problem than it looks: it exposes how aged (obsolete is a better word, I think) is our graphics system. Now, Athens will solve that problem, but there is no magic to do that can make the old graphics infrastructure to work with new hardware requirements, any adaptation of it will take a lot of work, and probably will not reach a good place... So, IMO the way to go is continue the efforts for make Athens work, and move morphic to work with it as soon as possible. Esteban ps: what? are you saying that we should remove something that is there since 1980? Yes I am! :) On Oct 12, 2012, at 10:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Sorry but we are a tiny team and we cannot run after everything at the same time. We should get focused > and release something. Igor is already fixing the VM plugin, library loading to avoid to have two libraries > of a given plugin and all the conflicts going together. > And we do not have retina mac right now. > > Stef > > >> :( >> >> On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Tudor Girba-2 wrote >>> Did anyone find a solution to this problem? >> >> I just got used to the fuzziness :) >> >> >> >> -- >> View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Oct. 12, 2012

Re: [Pharo-project] Pharo on retina display

by StÃ©phane Ducasse

Sorry but we are a tiny team and we cannot run after everything at the same time. We should get focused and release something. Igor is already fixing the VM plugin, library loading to avoid to have two libraries of a given plugin and all the conflicts going together. And we do not have retina mac right now. Stef > :( > > On Thu, Oct 11, 2012 at 3:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > Did anyone find a solution to this problem? > > I just got used to the fuzziness :) > > > > -- > View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567p4650783.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 12, 2012

Re: [Pharo-project] Interconnection of Morphic and Spec (was: [ANN] Phobos)

by StÃ©phane Ducasse

Pavel do you know VW spec, it is an array of symbol and spec is the same. We should change the api at some point. The point is that you do not code it by hand but that tools generate them. Now we are not to the point where a tools can generate them. But for us the OB is not the way to go because it is not flexible at all. Stef > Unfortunately it is not only about a layer between Morphic and Spec. > Whole Spec design is greatly conforming to Morphic. Check out Spec > definitions, they look almost like transcription of Morphic calls > > MethodToolbar class >> defaultSpec > <spec> > ^ { #Panel. > #changeTableLayout. > #listDirection:. #rightToLeft. > #addMorph:. {#model. #browseModel.}. > #addMorph:. {#model. #sendersModel.}. > #addMorph:. {#model. #implementorsModel.}. > #addMorph:. {#model. #versionModel. }. > #addMorph:. {#model. #dropListModel.}. > #hResizing:. #spaceFill. > #vResizing:. #shrinkWrap. } > > Of course these methods are implemented only in Morphic classes. Whole > layout management is directly taken from Morphic. And the Spec > definitions are unclear and hard to read. They are composed almost > solely from symbols so it is hard to work with and analyze them with > our development tools. We have such beautiful metalanguage where to > create DSL is so easy... > > In comparison with OmniBrowser the Spec is big step back. Sorry, I do > not want to be ugly but I started this impression when I was working > on Periscope and since that time it is deeper and deeper. > > Cheers, > -- Pavel > > > > > > On Thu, Oct 11, 2012 at 10:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 11 October 2012 20:52, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> This method is actually the only one from ComposableModel with direct Morphic binding :) >>> >>> >>> I am still trying to move that away, but I needed the rebuild to work >>> >> i think you can introduce own protocol (and put it as extension to >> morphic, if you want to) >> so, instead of saying >> >> widget removeAllMorphs >> >> you will use own extension method ,like: >> >> widget specRemoveAllChilds >> >> etc (spec here is namespacing prefix for a method, to indicate that it >> belongs to spec package >> and to indicate that it is a contract implied between spec and widget) >> >>> Ben >>> >>> On Oct 11, 2012, at 8:49 PM, Pavel Krivanek wrote: >>> >>>> Hi Ben, >>>> >>>> I really would like to write Spec binding for Phobos (Esteban will >>>> want to do it for Mars etc.). But, how to say that, Spec was not >>>> written with UI Independence in mind :-) Very basic example of that >>>> fact: >>>> >>>> ComposableModel>>buildWithSpec: aSpec >>>> "Build the widget using the spec name provided as argument" >>>> | widget | >>>> >>>> (self spec notNil and: [ self needRebuild not ]) >>>> ifTrue: [ | old | >>>> self needRebuild: true. >>>> old := self widget. >>>> old removeAllMorphs. >>>> self ensureExtentFor: old. >>>> widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. >>>> widget submorphs do:[ :e | old addMorphBack: e ]. >>>> self spec instance: old. >>>> ^ old ] >>>> ifFalse: [ widget := SpecInterpreter buildMorphFor: self withSpec: aSpec. ]. >>>> >>>> self ensureExtentFor: widget. >>>> >>>> ^ widget >>>> >>>> Can you please do at least basic steps in the architecture of Spec to >>>> make it more independent on Morphic? >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> On Wed, Oct 10, 2012 at 12:10 AM, Benjamin >>>> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>>> It was part of my battle plan to rule the world ;) >>>>> >>>>> We wanted with Nico to part it to Amber to get the Javascript part for free, then generate some XUL :) >>>>> >>>>> Anyway, really cool job, and impressive as well :) >>>>> >>>>> Ben >>>>> >>>>> On Oct 9, 2012, at 11:07 PM, StÃ©phane Ducasse wrote: >>>>> >>>>>> It looks really nice. >>>>>> I imagine that Spec could generate XUL too. >>>>>> >>>>>> Stef >>>>>> On Oct 9, 2012, at 9:48 PM, Pavel Krivanek wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I would like to introduce you Phobos - the XULRunner based Smalltalk >>>>>>> framework for development of native GUI with standard look&feel for >>>>>>> Linux, Mac OS X and Windows. >>>>>>> >>>>>>> It is based on Zinc, WebSockets and Seaside continuations. For more >>>>>>> information including more screenshots see the project page: >>>>>>> >>>>>>> http://code.google.com/p/phobos-framework/ >>>>>>> >>>>>>> You should pay attentions to FAQ too: >>>>>>> http://code.google.com/p/phobos-framework/wiki/FAQ >>>>>>> >>>>>>> Phobos has Seaside-like components and rendering style, can combine >>>>>>> XUL with HTML or SVG, supports printing etc. >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>>> <01.png> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Oct. 12, 2012

[Pharo-project] [update 2.0] #20335

by Marcus Denker

20335 ----- Issue 6786: TextEditor loses selection interval on right-click http://code.google.com/p/pharo/issues/detail?id=6786 Issue 6789: Open MCRepository after adding it http://code.google.com/p/pharo/issues/detail?id=6789 Issue 6781: Freetype startup + some cleanup http://code.google.com/p/pharo/issues/detail?id=6781 -- Marcus Denker -- http://marcusdenker.de

Oct. 12, 2012