June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Dark Themes and Menu...

by Nicolai Hess

2014-06-03 20:18 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > When showing the world menu, there is an issue with the Dark Themes. > > MenuMorph>>drawOn: aCanvas > "Draw the menu. Add keyboard-focus feedback if appropriate" > > super drawOn: aCanvas. > > (ActiveHand notNil > and: [ActiveHand keyboardFocus == self > and: [self rootMenu hasProperty: #hasUsedKeyboard]]) > ifTrue: [ > aCanvas > frameAndFillRectangle: self innerBounds > fillColor: Color transparent > borderWidth: self theme menuBorderWidth > borderColor: self theme menuKeyboardFocusColor > ]. > > > looks for > > menuBorderWidth and menuKeyboardFocusColor. > > When hitting a key that doesn't exists in the menu, I had the redcross. > > Defining the methods solved it. > > Thanks for fixing the themes. > > Phil > This happens for the non dark Pharo3Theme too. And in the latest pharo40, only menuKeyboardFocusColor is missing. The menuBorderWidth method is defined in UITheme. nicolai

June 3, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Pavel Krivanek

I'm really surprised how little we need to make TextMorph work with basic bitmap fonts: TAbleToRotate StrikeFont->#readFromStrike2: StrikeFont->#readFromStrike2Stream: StrikeFont->#displayLine:at: StrikeFont->#characters:in:displayAt:clippedBy:rule:fillColor:kernDelta:on: StrikeFont->#height StrikeFont->#ascent StrikeFont->#descent StrikeFont->#installOn:foregroundColor:backgroundColor: BitBlt->#installStrikeFont:foregroundColor:backgroundColor: StrikeFont->#glyphs StrikeFont->#displayString:on:from:to:at:kern: StrikeFont->#characterToGlyphMap StrikeFont->#createCharacterToGlyphMap StrikeFont->#xTable String->#asMorph StringMorph class->#contents: StringMorph class->#contents:font: StringMorph class->#contents:font:emphasis: StringMorph->#initialize StringMorph->#initWithContents:font:emphasis: StringMorph->#contents: StringMorph->#privateSetContents: StringMorph->#fitContents StringMorph->#measureContents StringMorph->#fontToUse AbstractFont->#widthOfString: AbstractFont->#widthOfString:from:to: StrikeFont->#widthOf: StringMorph->#minimumWidth StringMorph->#fullBounds StringMorph->#contents StringMorph->#areasRemainingToFill: StringMorph->#drawOn: StringMorph->#handlesMouseDown: StringMorph->#isEditable: StringMorph class->#editableStringMorph StringMorph->#isTranslucentButNotTransparent WorldMorph->#acceptDroppingMorph:event: Morph->#justDroppedInto:event: StringMorph->#imageForm:forRectangle: 2014-06-03 15:54 GMT+02:00 stepharo <stepharo(a)free.fr>: > Nice! > Alain restarted to work on Bloc and the result looks nice. I'm trying to > get some influence and rewrite clean what I see that > can be cleaned. > > Stef > > > Hi, >> >> I created a job that bootstraps MorphicCore - an image that contains >> runable subset of Morphic that is able only to display a simple morph and >> handle mouse and keyboard events on it. Please, try to test the image on >> Mac. >> >> https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo- >> 4.0-Bootstrap-Step-3.0-ConfigurationOfMorphicCore/ >> >> Cheers, >> -- Pavel >> > > >

June 3, 2014

Dark Themes and Menu...

by phil＠highoctane.be

When showing the world menu, there is an issue with the Dark Themes. MenuMorph>>drawOn: aCanvas "Draw the menu. Add keyboard-focus feedback if appropriate" super drawOn: aCanvas. (ActiveHand notNil and: [ActiveHand keyboardFocus == self and: [self rootMenu hasProperty: #hasUsedKeyboard]]) ifTrue: [ aCanvas frameAndFillRectangle: self innerBounds fillColor: Color transparent borderWidth: self theme menuBorderWidth borderColor: self theme menuKeyboardFocusColor ]. looks for menuBorderWidth and menuKeyboardFocusColor. When hitting a key that doesn't exists in the menu, I had the redcross. Defining the methods solved it. Thanks for fixing the themes. Phil

June 3, 2014

Re: [Pharo-dev] Regular Hangouts

by Sebastian Sastre

Glad to hear about this. Looking forward to invites On May 31, 2014, at 3:10 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I would really like to launch regular hangouts because I would like to build more contacts inside the community. > I was thinking about every two weeks around 17h-18h > > What do you think? > > Stef >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by Frank Shearar

On 3 June 2014 13:46, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > 2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> >> On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello, >> >> It happens sometimes when you edit a blockClosure code and that the >> debugger cannot find it on stack. >> >> >> Why would the debugger need to find a context for an edited block? >> The only reason I see would be on-stack replacement, but AFAIK the >> debugger doesn't do that, does it? >> >> >> I have spotted this problem too, outside block closures. It is not every >> time but it happens occasionally. >> I think is some sort of bug :( > > > Yeah I also had the problem ... > > Fortunately, one of the debugger implementor (that I will not name here) is > working in our team right now and she may be able to fix it :-) I started implementing this for Squeak, and then got snowed under by Real Life :( Had that not happened, you might have been able to spare some cycles. Sorry! frank >> Esteban >> >> >> >> Isn't that your case ? >> >> >> 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> >>> While debugging, I modify the code of the method, then accept, then >>> restart. >>> >>> But when going back to the method in the browser, it is unchanged. >>> >>> What I am doing wrong or is this something other people do encounter? >>> >>> I didn't had this in 2.0 >>> >>> Phil

June 3, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Ben Coman

June 3, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Ben Coman

June 3, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Igor Stasenko

On 31 May 2014 02:43, Darrin Massena <darrin(a)massena.com> wrote: > Thanks for all the great info Ronie! > > > On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Hello, >> >> I am also interested on this topic. For what I saw from NBOpenGL, Igor >> was generating the bindings from older specifications of the OpenGL API. >> Those older specifications are in a deprecated DSL. >> >> The newer versions of the OpenGL APIs are available in some XML files >> provided by Khronos Group. In this link >> http://www.opengl.org/registry/#specfiles another link for a subversion >> repository( >> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) >> with those XML files is available, along with the formal OpenGL specs. >> >> Because they are now in those XML files, we need new generator for OpenGL >> 3.3-4.0. >> > > OK. Where is the old generator? I will look into it if nobody is already > doing so. > > Everything should be hosted at http://www.smalltalkhub.com/#!/~PharoExtras/NBOpenGL see OpenGL-Specs <http://www.smalltalkhub.com/#%21/%7EPharoExtras/NBOpenGL/packages/OpenGL-Sp…> package please give me your name so i will add you as contributor, so you can commit changes there. > Another question, a core profile context is really needed? Why not >> starting working with a compatibility profile?. OpenGL API deprecation does >> not depend on us, it depends on what the Khronos Group and the graphics >> card maker decide to do. In the x86 Desktop, the three big companies cannot >> remove the compatibility profile, otherwise lot of older video-games will >> stop working. >> >> Also, there are lots of graphic cards, specially older integrated in >> laptops that are only OpenGL 2.x. A better bet is to support at least the >> subset available in OpenGL 2.x that is also available in the core profile. >> > > Good points. Nevertheless, as I understand it, OSX does not provide a > compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or > greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 > core. So we are working with an API that was deprecated 6 years ago that > can only take advantage of a fraction of the power of our GPUs and is > discouraged/unavailable on mobile platforms. Maybe that is enough for some > things but I'd like to see the door opened for more. > > This makes me wonder what the compatibility philosophy of Pharo is. Is it > a goal that once something is developed in Pharo it will work unchanged on > all future Pharo versions? I imagine one of the liberating aspects of VMs > is that they can evolve, even incompatibility, because old software can > continue to run on old VMs. But I am new to Smalltalk/Pharo culture so > please educate me. > > Maybe we need a GL3ViewportMorph to live along side GLViewportMorph. > > >> As for plans for OpenGL support, normal and accelerated GUIs, I am >> working in OSWindow. >> > > I have read a little of this -- very exciting! > > >> OSWindow provides support to manage native operating system windows >> purely from image side. With Igor, we made a custom image and VM for Linux >> in which we removed almost everything graphic related from the VM. The only >> support needed in the VM is a small check for event presence in the VM >> heartbeat. >> >> For OSWindow, we made initially a XLib based back-end. To reduce >> maintenance efforts for Windows and Mac OS, I made a new backend based in >> SDL2. It is quite complete and I have tested mostly in Linux. For Windows I >> could make it work, not perfect so it needs more testing and a complete >> removal of the old Win32 drivers. I don't have a Mac for testing, but Alex >> is going to help me there. >> > > If there is something I can do to help with the Mac I would like to. > > I have to tell the CMakeVMMaker to also build SDL2 before building, >> instead of having to build/install it manually. After that I think that we >> can start integrating into Pharo 4. >> >> As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a >> window with an OpenGL context. I already made it work with NBOpenGL, the >> only tricky part is dependency order when loading the stuff in the image. >> > > Yes, SDL2 is the way to go. > Well, wellcome to minimum common denominator problem :) But anyways it is good to have SDL2 backend.. however i prefer a direct communication with platform, like that, avoiding possible inefficiencies and crippling feature set (because SDL must support all of them everywhere, which is not always possible). > In fact, I already started making a new 3D graphics engine Pharo, to >> rewrite Roassal 3D on top of this one in the near future. Soon I will be >> posting some screen-shots of this engine. >> > > Sounds interesting! > > >> With this graphics engine, I am also going to try to make an Athens >> backend, for accelerated vector graphics. Vectorial graphics with OpenGL >> are very hard to do fast, specially self intersecting bezier curves. >> Stencil based testing is simple, fast, supported and efficient for this job. >> > > Very nice. Is Athens used to render the main UI elements (windows, > buttons, bitmaps, text, etc?). > > It's not clear to me how the OSWindow work will result in a faster Pharo > UI. On OSX, at least, underneath everything is already an OS window that > supports GL and other accelerated calls but the Pharo graphics primitives > don't take advantage of this. Won't they need reworking? > because of exccesssssive buffering + implicit bits conversions. In short: the way how Morphic delivers pixels to screen is quite far from optimal. With direct access to native window/graphical context, we could do much faster.. and OSWindow gives us a precise control over data flow. > > Greetings, >> Ronie >> >> >> 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> darrinm wrote >>> > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually >>> > created or generated somehow? >>> > >>> > - darrinm >>> >>> >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > -- Best regards, Igor Stasenko.

June 3, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by stepharo

Nice! Alain restarted to work on Bloc and the result looks nice. I'm trying to get some influence and rewrite clean what I see that can be cleaned. Stef > Hi, > > I created a job that bootstraps MorphicCore - an image that contains > runable subset of Morphic that is able only to display a simple morph > and handle mouse and keyboard events on it. Please, try to test the > image on Mac. > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > Cheers, > -- Pavel

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by Clara Allende

haha, well, if any of you can provide a way to reproduce the problem, I will take a look. 2014-06-03 14:46 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > 2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >> >> On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello, >> >> It happens sometimes when you edit a blockClosure code and that the >> debugger cannot find it on stack. >> >> >> Why would the debugger need to find a context for an edited block? >> The only reason I see would be on-stack replacement, but AFAIK the >> debugger doesn't do that, does it? >> >> >> I have spotted this problem too, outside block closures. It is not every >> time but it happens occasionally. >> I think is some sort of bug :( >> > > Yeah I also had the problem ... > > Fortunately, one of the debugger implementor (that I will not name here) > is working in our team right now and she may be able to fix it :-) > > >> >> Esteban >> >> >> >> Isn't that your case ? >> >> >> 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> While debugging, I modify the code of the method, then accept, then >>> restart. >>> >>> But when going back to the method in the browser, it is unchanged. >>> >>> What I am doing wrong or is this something other people do encounter? >>> >>> I didn't had this in 2.0 >>> >>> Phil >>> >> >> >> >> >

June 3, 2014