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

Re: [Pharo-dev] shortcut change in pharo 50075

by stepharo

Thanks nicolas. What we are trying to do (not easy) is to use rubric for texteditor with the idea that it will be easier to migrate to Bloc. Stef Le 30/5/15 11:45, Nicolai Hess a Ã©crit : > in pharo 50075 some shortcuts are removed > (issue 15630 <https://pharo.fogbugz.com/default.asp?15630> Remove > duplicate shortcut definition (TextEditors actionMap vs KM)) > > This is by intention. They were defined in text editors action maps > and with the Keymapping framework (pragma keymap). > > Those were defined with two different "command"-keys > (alt and ctrl). > > This change is not yet visible, although I defined a postload > you will see the change only after > TextEditor/SmalltalkEditior initialize > > (all alt+ shortcut are removed now, only the > ctrl+ shortcuts should work) > > alt+space / ctrl+space -> select word > alt+b/ctrl+b browseIt > alt+c/ctrl+c copy > alt+x/ctrl+x cut > alt+v/ctrl+v paste > alt+f/ctrl+f find > > Some "duplicate" shortcuts weren't removed because the shortcut > defined with the keymap pragma don't work (at least on windows). > > For example: > > ctrl+a/alt+a defined with the action map > and ctrl+a defined by keymap pragam > this wasn't remove, because ctrl+a does not work on windows vm > > ctrl+m/alt+m defined by the action map > ctrl+m defined by keymap pragma > this wasn't remove, because ctrl+m does not work on windows vm > > > please test the 50075 image, reinitialize editors subclasses > and give feedback (linux and mac users too). > > > thank you > > nicolai

May 31, 2015

Re: [Pharo-dev] About category

by stepharo

>> Now I have a question what is a class category? > IDK what it is currently, but I wish it was a logical domain tag (or > multiple) which had nothing to do with packaging ;) So sleeping on it I realized that we use category has a tag that embeds the package name. So I will only clean the method api to use protocol. I did and lost it. Stef

May 31, 2015

Re: [Pharo-dev] System Morphs in OSWindows

by Ben Coman

On Sun, May 31, 2015 at 1:10 AM, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > I am not sure I understand the first part of your mail. On Windows I often use dual-screen (two normal size screens). Typically an application's <Maximise> button maximises to a single screen only. So I need to manually resize the window to get with Pharo to cover both screens. Other applications** tend to provide two windows, so that each can be <Maximised> to a screen each. It seems SDL provides the potential to do this, but your example shows each tool being opened in its own native window. It could be good for Pharo to have a native window per screen, so that Pharo tools opened within that window. For example, from a browser in a second (SDL) window, do <senders> will bring up that tool in the same window as the browser. But others may prefer every tool open in its own native window. So do whatever is easiest first. cheers -ben > But as for the Raspberry application it should be possible to do it with > OSWindow since SDL library seems to be supported on Raspberry. > You just have to use your normal Pharo environment for your standard sized > screen and you open an OSWindow with your chosen application displayed > inside for your embedded LCD screen. > I don't know about hardware limitations though. > > 2015-05-30 17:33 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> On Sat, May 30, 2015 at 4:16 PM, Matthieu Lacaton >> <matthieu.lacaton(a)gmail.com> wrote: >> >> I think it would be better to name these for their function rather >> >> than the package: >> >> Nautilus openInExternalWindowOnPackage: nil. >> >> GTPlayground external openInExternalWindow. >> >> ThreadSafeTranscript external openInExternalWindow. >> >> >> >> I don't know if its a workable idea, but maybe something like >> >> Nautilus external openInOSWindowOnPackage: nil. >> >> GTPlayground external openInOSWindow. >> >> ThreadSafeTranscript external openInOSWindow. >> > >> > >> > It is a workable idea, we just need to agree on a syntax. >> > >> > >> >> Also good would be if an existing Morph could be moved to an external >> >> window. From a menu choice would be entirely sufficient, but >> >> super-bonus points for being able to drag it. This might also >> >> facilitate a usage like this (but again not sure if thats a desirable >> >> paradigm)... >> > >> > >> > >> >> >> >> (Nautilus external openInOnPackage: nil) moveToExternalWindow. >> >> (GTPlayground external openInOSWindow) moveToExternalWindow. >> >> (ThreadSafeTranscript external openInOSWindow) moveToExternalWindow. >> > >> > >> > This should be possible but I see two different ways of doing so : >> > >> > - First we could keep the same Morph and dynamically change some of its >> > features to match the requirements of an external window ( for example >> > the >> > action done when clicking on the close / expand / reduce boxes are not >> > the >> > same but there are other differences). Then we remove it from the World >> > and >> > open it in an OSWindow. >> > - Or we could "save the state of the Morph" then delete it and directly >> > open >> > a new one suited for external window. I've quoted "save the state of the >> > Morph" because if this option is chosen it will need to be refined. >> > >> > As for the "drag it outside part" I am sure it could be done. Currently >> > when >> > you are dragging a Morph, as soon as the HandMorph goes out of the >> > World, >> > when you release the mouse button the Morph goes back at its initial >> > place >> > so we could just change this behavior to make it move to an external >> > window >> > instead. But to be more flexible,maybe we could just keep both behavior >> > and >> > chose between one and the other by pressing a hotkey while dragging the >> > Morph. >> > >> > BTW, I've recorded a short video to show you what it is possible to do >> > with >> > the new SDL version (it should also illustrate what I told Nicolai >> > earlier) >> > : >> > >> > https://www.dropbox.com/s/m27aa0flanocnlr/OSWindowMorph.mkv?dl=0 >> > >> > As you can see if you put the Morph inside the boundaries of the World, >> > it >> > seems as if it was actually opened in the world (put aside some >> > differences >> > like the fonts etc. but this is only due to the Athens rendering of >> > Morphs >> > and it won't matter in Bloc). >> > For now it is heavily buggued (you can't opened two windows like that >> > without crashing the VM :/) but SDL 2.0.4 is still in developement so I >> > won't work more on it until it is released. >> > >> > >> >> Where we have for example Meta-O-O to open a browser, it could be >> >> Meta-E-O to open in an external window. >> >> Also, a hotkey could be held down when opening from a menu - similar >> >> paradigm to web browsers between opening a new tab or opening a new >> >> window. >> > >> > >> > Yeah that's a good idea. For the moment when opening from a menu the >> > left >> > and right clicks have the same behavior so it could even be something >> > like >> > left click => world and right click => external window. >> > >> > >> >> As well a Preference so that this can be set globally. A multitude of >> >> open windows could be handled with a menu item in the task bar "Close >> >> all > external windows". >> >> >> >> btw, I presume Morphs in these windows would still appear in the task >> >> bar as usual. >> > >> > >> > I am not sure about that because as OS - Windows they appear in the >> > taskbar >> > of your OS and you can already manage them from here. >> >> Sure one option is to have a native window for every Morph. The other >> is to have only a WorldMorph as a native window holding other Morphs. >> I'm not sure which one I'd prefer, but I'd sure like the option of the >> latter. An example use-case... Torsten's recent video of Pharo on >> Raspberry Pie... not sure if the hardware is up to it, but it would be >> great to have a Pharo application displaying on a low resolution >> embedded LCD screen, with a normal development environment on a >> standard sized screen running off the same Pie. >> cheers -ben >> >> > >> > >> >> How will the existing World paradigm play into this? Will external >> >> windows be part of the same World? Or maybe the existing World can >> >> have another level below it called like World-Screen? >> > >> > >> > The existing World paradigm will probably change with Bloc I guess. At >> > first >> > I thought that all these windows could be part of the same Bloc-space >> > and >> > that this Bloc-space would be dedicated to held external windows but I >> > really need to speak with Alain about that. >> > >> > Many thanks for your feedback and ideas ! >> > >> > Cheers, >> > >> > Matthieu >> > >> > 2015-05-30 8:16 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >> >> >> >> >> - If possible I'd like not to have to modify any Bloc code. If it is >> >> not >> >> possible then as little as possible. >> >> >> >>> What is the aversion here? Bloc is still developing and since its >> >>> semantics are based on old-Morphic maybe this use-case is not >> >>> considered. Adding this use-case may be an opportunity to make the >> >>> overall system architecture simpler instead of needing workarounds. >> >>> To what degree would Bloc already support this? >> >> >> >> >> >> What matthieu wants to say is that opening a window in an external >> >> sufrace >> >> should >> >> not impose to have some hacks into bloc and alain agrees with that and >> >> will modify the >> >> bloc architecture to handle separate native windows. >> >>>> >> >>>> - These windows should be persistent but maybe not exactly like >> >>>> morphs. >> >>>> It >> >>>> could be a button that the user needs to press in the window to >> >>>> toggle >> >>>> the >> >>>> persistence on and off (a bit like in the world menu to stick it to >> >>>> the >> >>>> world if you see what I mean). >> >> >> >> >> >> I'm not sure that you want to have that behavior. Open windows should >> >> be >> >> persisted. >> >> >> >>> As well a Preference so that this can be set globally. A multitude of >> >>> open windows could be handled with a menu item in the task bar "Close >> >>> all > external windows". >> >>> >> >>> btw, I presume Morphs in these windows would still appear in the task >> >>> bar as usual. >> >>> >> >>> >> >> >> >> >> > >> >

May 31, 2015

Libgit2 and Windows vm build

by Nicolai Hess

Latest change for libgit2 makes the Windows vm bulid failing. (See Jenkins job)

May 30, 2015

Re: [Pharo-dev] About category

by Sean P. DeNigris

stepharo wrote > Now I have a question what is a class category? IDK what it is currently, but I wish it was a logical domain tag (or multiple) which had nothing to do with packaging ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/About-category-tp4829542p4829554.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 30, 2015

Re: [Pharo-dev] About category

by Thierry Goubier

Le 30/05/2015 21:44, stepharo a Ã©crit : > Hi guys > > We introduced protocol for sorting methods and package for categories > but we left many users of categories. > I think that it would be good to finish the clean this. > I'm cleaning some of the method level one. > Now I have a question what is a class category? Because it does not look > like a package name > > Point category -> 'Kernel-basicObject" > Point package name -> 'Kernel' (Point package classTagNamed: (Point package toTagName: Point category)) name -> #BasicObjects i.e. class category = package name + tag name Thierry > Stef > > > >

May 30, 2015

Re: [Pharo-dev] About category

by Cyril Ferlicot

A category is not a sub classification into the package ? A category is not to a package what a protocol is for a class ? A way to have some classification on a package. On 30 May 2015 at 21:44, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > We introduced protocol for sorting methods and package for categories but we > left many users of categories. > I think that it would be good to finish the clean this. > I'm cleaning some of the method level one. > Now I have a question what is a class category? Because it does not look > like a package name > > Point category -> 'Kernel-basicObject" > Point package name -> 'Kernel' > > Stef > > -- Cheers Cyril Ferlicot

May 30, 2015

Re: [Pharo-dev] what is a GTSpotterRecorderCategorySelectedEvent?

by Tudor Girba

Hi Stef, I am not sure I understand the question. This class records the selection of a Spotter category, not a system category. This is the thing that appears in light gray in Spotter (like Classes, Packages, ... ) Cheers Doru On Sat, May 30, 2015 at 9:51 PM, stepharo <stepharo(a)free.fr> wrote: > A GTSpotterRecorderCategorySelectedEvent models the action of selecting a > category in the search results. This event stores the name of the category > and the number of results that were matched by the current query. > > Instance Variables > categoryLabel: <Object> > elementCount: <Object> > > categoryLabel > - xxxxx > > elementCount > - xxxxx > > > Is a category related to class/method? > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

May 30, 2015

what is a GTSpotterRecorderCategorySelectedEvent?

by stepharo

A GTSpotterRecorderCategorySelectedEvent models the action of selecting a category in the search results. This event stores the name of the category and the number of results that were matched by the current query. Instance Variables categoryLabel: <Object> elementCount: <Object> categoryLabel - xxxxx elementCount - xxxxx Is a category related to class/method? Stef

May 30, 2015

About category

by stepharo

Hi guys We introduced protocol for sorting methods and package for categories but we left many users of categories. I think that it would be good to finish the clean this. I'm cleaning some of the method level one. Now I have a question what is a class category? Because it does not look like a package name Point category -> 'Kernel-basicObject" Point package name -> 'Kernel' Stef

May 30, 2015