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

Re: [Pharo-dev] functions keys

by Pablo R. Digonzelli

Guille , functions key does not generate event at all. I think it is a problem for some applications. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Guillermo Polito" <guillermopolito(a)gmail.com> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> CC: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Enviados: Lunes, 30 de Junio 2014 19:26:23 Asunto: Re: [Pharo-dev] functions keys To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli < pdigonzelli(a)gmail.com > wrote: After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 30, 2014

Re: [Pharo-dev] [Pharo-users] functions keys

by Nicolai Hess

Yes, no function keys. 2014-07-01 0:06 GMT+02:00 Pablo R. Digonzelli <pdigonzelli(a)gmail.com>: > > After exploring the image I believe functions keys (F1,F2, etc ) are not > handling by KeyboardEvent class. > I think it is very common use that function keys in business applications. > Someone know if i am true about this topic? . > Or maybe someone handling functions keys in an application? > > TIA > > ------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > >

June 30, 2014

Re: [Pharo-dev] functions keys

by Guillermo Polito

To handle function keys you should handle the keyup or keydown event. Then, the KeyboardEvent has a #key method to get the pressed key. Take a look at the Key class side methods to access well known keys. Guille On Tue, Jul 1, 2014 at 12:06 AM, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > > After exploring the image I believe functions keys (F1,F2, etc ) are not > handling by KeyboardEvent class. > I think it is very common use that function keys in business applications. > Someone know if i am true about this topic? . > Or maybe someone handling functions keys in an application? > > TIA > > ------------------------------ > *Ing. Pablo Digonzelli* > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > >

June 30, 2014

numeric pad

by Pablo R. Digonzelli

i actualized the vm for linux , but numeric pad of keyboard does not work. The keys are captured (exists KeboardEvent ) but the keys are not displaying in workspace for example. TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 30, 2014

functions keys

by Pablo R. Digonzelli

After exploring the image I believe functions keys (F1,F2, etc ) are not handling by KeyboardEvent class. I think it is very common use that function keys in business applications. Someone know if i am true about this topic? . Or maybe someone handling functions keys in an application? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 30, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Nicolai Hess

The real question was: Why can't we draw a text with StrikeFont and with Athens. Igor, can't we use AthensCairoText (cairo toy text api) for non-truetype fonts? 2014-06-21 1:20 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Gi Igor, > > For DrGeo it is not a workable option to have different fonts in Morphic > widget and Athens canvas (I explained earlier why). > However I found the scaling trick of draw text to work reasonably well. > Not full perfect as from time to time I can see some artifact. > > Thanks > > Hilaire > > > > > Le 20/06/2014 15:32, Igor Stasenko a Ã©crit : > > Sure, you can do: make sure you don't render text with same font in > > Morphic UI and Athens, so they don't interfere with each other. > > There's no easy way to get rid of interference, because it would require > > changing Freetype package and its plugin in order to establish a single > > font management point and funnel all requests to freetype library > > through it. > > > > -- > Dr. Geo http://drgeo.eu > iStoa - https://launchpad.net/istoa > > >

June 30, 2014

Re: [Pharo-dev] Versioner

by Dale Henrichs

Esteban, Just to be clear, I believe that there should be Smalltalk scripting/cli from within the image (augment workspace usage) as well as from without ... more food (for lunch) thought:) Dale On Mon, Jun 30, 2014 at 11:36 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > 2014-06-30 13:15 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com > >: > > Smalltalk with it's heavy reliance on GUI-based tools is not quite as > easy > > to customize (for several reasons) ... before knickers get knotted, > please > > keep in mind that I think that customizable GUI-based tools are > important, > > it's just that the GUI raises the entry level bar a bit higher than it > needs > > to be... > > > > There is room in Smalltalk for plain old-fashioned scripts (workspaces > don't > > quite cut it in this regard) that can be easily shared and customized > (and > > written in Smalltalk) ... > > > > anway, some (breakfast) food for thought... > > This is, in my opinion, a flaw that affects any system born as a GUI. > There was no CLI culture in the past. > It happens to Smalltalk, obviously, and also affected Microsoft > (another UI centric OS) who had to put a lot of effort (and $$$) to > add command line support for most of their solutions, as a response to > devops and similar users. Mac got developer traction since they put > BSD underneath a fancy GUI. > > According to the Unix Philosophy ( > http://en.wikipedia.org/wiki/Unix_philosophy) > > Smalltalk, and Pharo, are compliant with the "Rule of Modularity" > whitin the image, but not with the "Rule of composition" as seen from > external programs. > > Pharo's command line support is certainly better than before. > But we're not there yet, when even web pages are mostly > composed/scaffolded/provisioned using CLI tools today instead of using > behemont tools like Dreamweaver/Expression. > > This is also food for thought. In case anybody is still hungry. :) > > Regards! > >

June 30, 2014

Re: [Pharo-dev] Versioner

by Stephan Eggermont

Kilon wrote: >I disagreed with this Stephan > >"That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my >fears are unfounded." > >this what I was replying to. Ok. The concrete problem we ran into with the current version of Versioner is that it wants to resolve dependencies to exact versions. For configurations depending on Seaside, Magritte or Grease, this is normally unwanted. They should depend on the symbolic release versions. With the high number of changes in Pharo, exact versions have a short lifetime. Dale wrote: >In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) > it is much easier to construct custom "tools" to support variations in workflow >... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... In order to work together effectively in open source projects it is important that contributors know what workflow is used in a project. That is easier when the number of different workflows is limited. Because projects depend on other projects the number of combinations of workflow is very large. Scriptable tools can easily support these resulting combinations. Building a GUI tool that is both very flexible and very easy to use seems to be less easy. Stephan

June 30, 2014

Re: [Pharo-dev] Versioner

by Esteban A. Maringolo

2014-06-30 13:15 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy > to customize (for several reasons) ... before knickers get knotted, please > keep in mind that I think that customizable GUI-based tools are important, > it's just that the GUI raises the entry level bar a bit higher than it needs > to be... > > There is room in Smalltalk for plain old-fashioned scripts (workspaces don't > quite cut it in this regard) that can be easily shared and customized (and > written in Smalltalk) ... > > anway, some (breakfast) food for thought... This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI. According to the Unix Philosophy (http://en.wikipedia.org/wiki/Unix_philosophy) Smalltalk, and Pharo, are compliant with the "Rule of Modularity" whitin the image, but not with the "Rule of composition" as seen from external programs. Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression. This is also food for thought. In case anybody is still hungry. :) Regards!

June 30, 2014

Amber frontend with Pharo backend

by Sebastian Sastre

Hi guys, cross-posting to Amber groupâ¦ Iâve recently published the code of http://tasks.flowingconcept.com Here: http://github.com/sebastianconcept/tasks Have fun sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

June 30, 2014