November 2015 - Pharo-users

Re: [Pharo-users] How to find the cursor position relative to its text for TextMorph or RubTextFieldArea

by Dimitris Chloupis

because its simpler to understand and because I made it work the way I wanted faster than the Rubric alternatives. For example finding the cursor position for a RubScrolledTextMorph is even worse and is located at textArea selectionInterval which I did not even find by myself because the name would never have me guessed that selection had anything to do with cursor position. But I was told so by another smalltalker at slack chat. And even though my code formating worked great with TextMorph via keyStroke message when I tried to port my code to the Rubric keyStroke alternative it stopped working and I did not manage to find out why before I finally managed to find how to get the cursor position from a TextMorph. Generally speaking Morphic is my first choice for the simple fact that when it comes to Rubric, Glamour, Spec or whatever else Morphic still remains the basis. So if I am going to learn Morphic anyway then I might as well make it my first choice and when it cant do what I want the easy way then I will look into the alternatives. Frankly I really like Morphic. Still new to it, but its generally design makes more sense to me than other pharo GUI APIs. On Wed, Nov 11, 2015 at 7:30 PM Alain Plantec via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello Dimitris, > Why do you use TextMorph and not RubScrolledTextModel or RubTextFieldMorph > ? > Cheers > Alain > > On 11 Nov 2015, at 16:28, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > and to answer my own question the answer is > > TextMorph editor pointIndex. > > And now I can create a specialized input field only for time that > automatically formats to HH:MM:SS > > On Wed, Nov 11, 2015 at 3:21 PM Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> At first I thought that TextMorph>>cursor would return me the position of >> the cursor relative to its text so if I have a text like "hello" and cursor >> (that blinking thing) was at "o" it would return 6 but no, whatever >> position I try it returns always 1 . With rubric I found no way to do this >> either. >> >> Anyone has a clue, or to I need some kind of pharo dark magic ? Is this a >> bug , a feature or something in between ? >> > >

Nov. 11, 2015

Re: [Pharo-users] How to find the cursor position relative to its text for TextMorph or RubTextFieldArea

by Alain Plantec

Hello Dimitris, Why do you use TextMorph and not RubScrolledTextModel or RubTextFieldMorph ? Cheers Alain > On 11 Nov 2015, at 16:28, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > and to answer my own question the answer is > > TextMorph editor pointIndex. > > And now I can create a specialized input field only for time that automatically formats to HH:MM:SS > > On Wed, Nov 11, 2015 at 3:21 PM Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > At first I thought that TextMorph>>cursor would return me the position of the cursor relative to its text so if I have a text like "hello" and cursor (that blinking thing) was at "o" it would return 6 but no, whatever position I try it returns always 1 . With rubric I found no way to do this either. > > Anyone has a clue, or to I need some kind of pharo dark magic ? Is this a bug , a feature or something in between ?

Nov. 11, 2015

Re: [Pharo-users] How to find the cursor position relative to its text for TextMorph or RubTextFieldArea

by Dimitris Chloupis

and to answer my own question the answer is TextMorph editor pointIndex. And now I can create a specialized input field only for time that automatically formats to HH:MM:SS On Wed, Nov 11, 2015 at 3:21 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > At first I thought that TextMorph>>cursor would return me the position of > the cursor relative to its text so if I have a text like "hello" and cursor > (that blinking thing) was at "o" it would return 6 but no, whatever > position I try it returns always 1 . With rubric I found no way to do this > either. > > Anyone has a clue, or to I need some kind of pharo dark magic ? Is this a > bug , a feature or something in between ? >

Nov. 11, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Alexandre Bergel

> One thing that slows down spotter is the fact that we display now all entries from the world menu, which we should change. > Also the extension for CatalogBrowser does an HTTP request every time one opens spotter. I am for changing this, or > at least for not displaying the CatalogBrowser by default until one starts searching. Woaaaaâ¦. That is why opening Spotter on the other side of the World is so slowâ¦ Yes please, remove this. Really. It does not bring much. Alexandre

Nov. 11, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Tudor Girba

Hi, It was chosen a while ago that the Global shortcuts are checked first, before the local ones. The local ones propagate from bottom to top. The idea here was to guarantee global behavior, such as Shift+Enter for popping out things like Spotter. I was not happy about that, but that was the choice. Now, I think that the global keymap mechanism should be used sparingly, and I think that using it for Cmd+o is a bit too much. Cheers, Doru > On Nov 11, 2015, at 12:22 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Ehm, or maybe fix event dispatch so it works properly? > It should always end up testing for event handling By the leaf morph at the given event position and work its way up if unhandled, not check top-down like the change to dispatchEvent:with: has ended up doing... > > Cheers, > Henry > >> On 11 Nov 2015, at 11:46 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> I actually think we should disable those shortcuts. >> >> The reason is that they âpollute" the global shortcut space: for example, you can now not use Cmd+o for any custom action in your own window, and that is less than ideal. >> >> The alternative is to use Spotter to spawn windows. The interesting thing there is that you do not need shortcuts for every specific windows because you can use regular search. For example, opening Playground is: Shift+Enter, p, Enter >> >> Cheers, >> Doru >> >> >>> On Nov 11, 2015, at 10:49 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2015-11-11 10:45 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> Hi, >>> >>> currently to open a Playground via shortcut one has to type <cmd>+o+w, that's because it used to open Workspace. >>> However since it now opens Playground the shortcut is no longer appropriate. >>> >>> So can we change it to <cmd>+o+p? >>> (This shortcut is currently occupied by Monticello Browser, but that can be movd to <cmd>+o+m which is free.) >>> >>> cmd+o+m would be >>> ctrl+o ctrl+m on windows, but ctrl+m does not work yet on windows. >>> >>> >>> You could argue that people are used to this shortcut, however that will not be true for newcommers, who will just see it as random naming (which it currently is). >>> >>> Peter >>> >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

Nov. 11, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Andrei Chis

> > Hi, > > I am totally against it because it's too much time to open it with the > spotter. A shortcut need to be a shortcut. If I need to open it via the > Spotter, I will use the mouse because it's the same time. > One more reason, when the image become too big sometime, the Spotter > need some time to initialize. On one of my latest image the spotter > needed ~3-4sec to open and initialize. > Just regarding the slowdown, if the image has no private data could you maybe share it? If you cannot can I send you some logging statements to see what takes so long. Normally there shouldn't be such a big slowdown. One thing that slows down spotter is the fact that we display now all entries from the world menu, which we should change. Also the extension for CatalogBrowser does an HTTP request every time one opens spotter. I am for changing this, or at least for not displaying the CatalogBrowser by default until one starts searching. Cheers, Andrei > > There is a lot of things that we cannot do easily only with the > keyboard, this is bad. So please, do not remove what works for now. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

Nov. 11, 2015

How to find the cursor position relative to its text for TextMorph or RubTextFieldArea

by Dimitris Chloupis

At first I thought that TextMorph>>cursor would return me the position of the cursor relative to its text so if I have a text like "hello" and cursor (that blinking thing) was at "o" it would return 6 but no, whatever position I try it returns always 1 . With rubric I found no way to do this either. Anyone has a clue, or to I need some kind of pharo dark magic ? Is this a bug , a feature or something in between ?

Nov. 11, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Ferlicot D. Cyril

Le 11/11/2015 11:46, Tudor Girba a Ã©crit : > I actually think we should disable those shortcuts. > > The reason is that they âpollute" the global shortcut space: for example, you can now not use Cmd+o for any custom action in your own window, and that is less than ideal. > > The alternative is to use Spotter to spawn windows. The interesting thing there is that you do not need shortcuts for every specific windows because you can use regular search. For example, opening Playground is: Shift+Enter, p, Enter > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > Hi, I am totally against it because it's too much time to open it with the spotter. A shortcut need to be a shortcut. If I need to open it via the Spotter, I will use the mouse because it's the same time. One more reason, when the image become too big sometime, the Spotter need some time to initialize. On one of my latest image the spotter needed ~3-4sec to open and initialize. There is a lot of things that we cannot do easily only with the keyboard, this is bad. So please, do not remove what works for now. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Nov. 11, 2015

Re: [Pharo-users] Roassal and custom morphs

by Alexandre Bergel

Thanks Dimitris for your nice words Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 11, 2015, at 4:10 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Yeap this is perfect . I even tried it with a simple transparent Morph openInWorld and it draws Roassal elements in transparent background , exactly as I wanted because I play a lot with transparency with my custom GUIs. I also like the elegance of the Roassal API very much, looks like I will be using it for adding some extra dynamic graphics to my custom guis so I dont rely completely on static images. Thank you both :) > > On Wed, Nov 11, 2015 at 1:41 AM Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > Excellent example :-) > > Alexandre > > > > On Nov 10, 2015, at 6:25 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > > > > > > On Tue, Nov 10, 2015 at 9:56 PM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > Am I correct to assume that I can easily embed Roassal visualizations inside morphs ? Also where is the official documentation ? is this still it ? > > > > http://agilevisualization.com/#book <http://agilevisualization.com/#book> > > > > Yes. > > > > Roassal itself is embedded inside a TRMorph, which is a ...morph. :) > > > > For example: > > > > [[[ > > |container button view es e| > > > > view := RTView new. > > container := BorderedMorph new. > > (button := PluggableButtonMorph new) > > label: 'I am a morph'; > > actionBlock: [ (view elements, view edges) do: [ :each | each color: Color random. each signalUpdate ] ]. > > > > es := RTBox new color: Color black; size: 50; elementsOn: #(1 2). > > e := RTLine new color: Color black; edgeFrom: es first to: es second. > > view addAll: es; add: e. > > es second translateBy: 100 @ 200. > > > > container addMorph: view canvas buildMorph. > > container addMorph: button. > > > > container openInWindow. > > ]]] > > > > Peter > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Nov. 11, 2015

Re: [Pharo-users] Changing playground and monticello shortcuts

by Peter UhnÃ¡k

On Wed, Nov 11, 2015 at 11:46 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I actually think we should disable those shortcuts. > > The reason is that they âpollute" the global shortcut space: Well they are global shortcuts, so that's to be expected. > for example, you can now not use Cmd+o for any custom action in your own > window, and that is less than ideal. > as far as I know events bubble up, so morphs can intercept them (which will break the global shortcut, but if the programmer sees it as appropriate...) > > The alternative is to use Spotter to spawn windows. The interesting thing > there is that you do not need shortcuts for every specific windows because > you can use regular search. For example, opening Playground is: > Shift+Enter, p, Enter > This takes significantly more time, and on top of that doesn't actually work, because the first group is History and not Menu... so this would open PetitParser browser for me. I don't see a problem in having global shortcuts for the most important tools, if the current key combinations are problem, then we should come up with different combinations. Peter

Nov. 11, 2015