- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Guillermo Polito

On Sun, Jul 8, 2012 at 2:52 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Benjamin Van Ryseghem-2 wrote > > > > If I were you, I would have put all the VIM shortcut in one class, > instead > > of putting them around but :) > > > I'll keep that in mind once I get it working ;-) > > > Benjamin Van Ryseghem-2 wrote > > > > Like that, you could add yours in a specific context, and remove them. > > > Any luck finding those detach* methods? Googling/Nabbling > "detachKeymapCategory" turned up nothing. > > Also, I think of my use case here for the "enter command mode" shortcut as > "Change the default shortcuts for a Morph class". It seems that what's > required for this type of use is a registration mechanism more like the > world menu. For the world menu, I can insert an entry at any level, not > just > an existing one, without overriding anything. In KM currently, in order to > do this, it seems we're forced to hitch a ride on an existing category. > Maybe a special pragma indicating that certain categories should be > attached > for the class by default. > > In summary, I'm still unclear on the relationship between the class-side > <keymap> defaults methods and changing shortcuts on the fly, but what seems > to be missing are: > * a way to register shortcuts/categories to be attached to a Morph class by > default > Nope :). Look at http://www.smalltalkhub.com/mc/Guille/Keymappings/main, in Keymapping-Morphic, KMWindowsKeymaps class>>buildGlobalKeymappingsOn:. The last line: aBuilder attachShortcutCategory: #Window to: SystemWindow. Those are static keybindings, and they were the first ones. I think I have to spend some hours in providing examples... > * a way to detach categories > I'll integrate them again. Ben, somehow the dettach* methods dissapeared from KMDispatcher in latest 2.0 :/. I'll have a look and integrate all of them in latest Keymapping version. > * a way to detach individual shortcuts > You mean removing a shortcut from a category? Or to ban a shortcut from a morph? Because here, I will be a bit strict with the nomenclature so we understand each other :) : - Static category keymappings: you attach a category to a class. ( The one in the example above ) - Dynamic category keymappings: you attach dinamically a category to an object. (the one you've used so far) - Dynamic object keymappings: you attach a single shortcut to an object, sending the #on:do: message So, were you using the third one? Removing a keymap from a category, which removes it from all the objects who use it, is easy but removing just for one object is not there, because the keymaps are looked up in the configuration, not flattened on the object. > Thanks, this is very exciting. We're *so* close to having this work... > Sean > > -- > View this message in context: > http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

July 9, 2012

Re: [Pharo-project] Solving the fact that http://source.lukas.renggli.ch/ is down

by Damien Cassou

On Sat, Jul 7, 2012 at 1:48 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Any idea why Lukas stops his servers? remember we have a dropbox folder with all mcz. Please ask if you are interested -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 9, 2012

[Pharo-project] View from an outsider [was Re: Pharo and Namespaces]

by Patrik Sundberg

On Jun 27, 2012; 4:27pm, Stephane Ducasse wrote: > On Jun 27, 2012, at 4:44 PM, James Foster wrote: > >> Stef, >> >> I'm sorry to hear about your burnout and I understand that you are not >> prepared to seriously discuss the issues that others have raised. I hope >> when the issue is raised again (it does seem to come up every year or >> so!) we can correct some of the misunderstandings that exist. > >yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. >Now for 20 we should finish all the open tracks we have. > >Stef Hi, A comment from a complete outsider: I've been following pharo on the side for the last year or so and am very impressed by both smalltalk as a language and pharo as an implementation. I am not trying to even voice an opinion of what's right to focus on for pharo project since that's not my place having nothing invested in it (so far, gearing up to add some pharo parts to my world). It did strike me that it could be interesting to hear the view from an outsider on what would draw interest and more users/developers to the project. Be it inspiration for pharo 2.1 or 3.0 or 4.0 :) I'll first state a belief: I believe that the explosive growth of ruby and python communities to some extent depended on good package management systems making it very easy for people to publish/share/collaborate on packages. A killer app to kick it off, but one needs easy collaboration to grow. On the back of that I'm very excited to see the following pharo efforts being close to coming together into something great: 1. Stripped down core kernel and bootstrap project 2. Fuel for fast serialization and deserialization (can be used for binary packages) 3. FileTree 4. Metacello scripting API 5. Metacella Git/Github integration 6. Tools such as Versionner on top of Metacello for ease of use 7. Namespaces/Environments In terms of getting a lot of people much more comfortable diving into the image world I think that list have great promise. If one can easily start with a minimal kernel, have some simple tooling such that one from e.g. the commandline can bootstrap it via Metacello configurations that pulls in both the parts of the base system one needs and project/application dependencies to get a working image for both development and deployment (via metacello groups for example) it has 2 benefits: 1. Reproducible process which means automation and testing a lot easier for projects (jenkins etc for applications), as well as deployment 2. It's a workflow that's quite similar to how one would for example work with ruby, rubygems and bundler (on a high level). Familiarity draws in more people - it shouldn't be at the cost of a good system, but if one can get both it's a definite positive. Once project/appliation bootstrapped like that and one is working in the image tools like Versionner and Metacello with git/github intregration will provide an excellent workflow for collaboration (push/pull/merge/branch/etc). Again I see 2 benefits: 1. Functionally solid (see e.g. the Practical Git for Smalltalk presentation by Dale) 2. It's familiar to outsiders and has a good chance of attracting new people. Even if one has great in image tooling it's very good to be able to be a "lazy" follower of a package/project via e.g. github (RSS feeds for changes, nice diffs accessible from any web browser, pull requests, graphical representation of branches etc etc). I for example would be much more likely to have learnt more on pharo implementation if I could have followed it on github for the last year. When collaboration increases and people share a lot of packages via e.g. git & github one tend to see exponential reuse and number of new packages created (on the back of what exists), and at least the ruby experience is the average number of package dependencies for a project increases. It's in that point of view I'm seeing namespaces/environments as an important addition. Prefixing names is doable and at a non-human level you can accomplish most of the same things, but on a human level I see it as important - and it gets more important the more collaboration and reuse of existing packages one accomplishes. A non-technical consideration is that developers these days kind of expects some form of namespacing to exist and not seeing it available is something to deter some possible adopters (rightly or wrongly, many times they wouldn't need namespaces/environments, but many may not reflect too deeply on that). I know I twigged at first seeing prefixing being used instead of some form of namespaces. >From that this perspective (namespaces/environments more important as more people are, reuse and collaboration happens) it seems quite sensible to put it after the other things on the todo list (as long as it doesn't goes away completely). Hopefully that's of some interest :) I'll continue my journey towards using pharo more - we shall see how it works out for me! Regards, Patrik -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4639158.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

[Pharo-project] [update 2.0] #20196

by Marcus Denker

20196 ----- Issue 6316: Restore display when launching transcripter via menu http://code.google.com/p/pharo/issues/detail?id=6316 Issue 6307: UI inform dialog should use our "growl" stuff http://code.google.com/p/pharo/issues/detail?id=6307 Issue 6293: Fix FIleSystemTest >> #testReferenceTo http://code.google.com/p/pharo/issues/detail?id=6293 -- Marcus Denker -- http://marcusdenker.de

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Benjamin

Here is the detach methods filed out. They are still extensions here, but they should be moved directly into KM We will succeed :P Ben On Jul 8, 2012, at 2:52 PM, Sean P. DeNigris wrote: > > Benjamin Van Ryseghem-2 wrote >> >> If I were you, I would have put all the VIM shortcut in one class, instead >> of putting them around but :) >> > I'll keep that in mind once I get it working ;-) > > > Benjamin Van Ryseghem-2 wrote >> >> Like that, you could add yours in a specific context, and remove them. >> > Any luck finding those detach* methods? Googling/Nabbling > "detachKeymapCategory" turned up nothing. > > Also, I think of my use case here for the "enter command mode" shortcut as > "Change the default shortcuts for a Morph class". It seems that what's > required for this type of use is a registration mechanism more like the > world menu. For the world menu, I can insert an entry at any level, not just > an existing one, without overriding anything. In KM currently, in order to > do this, it seems we're forced to hitch a ride on an existing category. > Maybe a special pragma indicating that certain categories should be attached > for the class by default. > > In summary, I'm still unclear on the relationship between the class-side > <keymap> defaults methods and changing shortcuts on the fly, but what seems > to be missing are: > * a way to register shortcuts/categories to be attached to a Morph class by > default > * a way to detach categories > * a way to detach individual shortcuts > > Thanks, this is very exciting. We're *so* close to having this work... > Sean > > -- > View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 8, 2012

[Pharo-project] pharo-2.0-tests Â» 32,mac - Build # 194 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > > If I were you, I would have put all the VIM shortcut in one class, instead > of putting them around but :) > I'll keep that in mind once I get it working ;-) Benjamin Van Ryseghem-2 wrote > > Like that, you could add yours in a specific context, and remove them. > Any luck finding those detach* methods? Googling/Nabbling "detachKeymapCategory" turned up nothing. Also, I think of my use case here for the "enter command mode" shortcut as "Change the default shortcuts for a Morph class". It seems that what's required for this type of use is a registration mechanism more like the world menu. For the world menu, I can insert an entry at any level, not just an existing one, without overriding anything. In KM currently, in order to do this, it seems we're forced to hitch a ride on an existing category. Maybe a special pragma indicating that certain categories should be attached for the class by default. In summary, I'm still unclear on the relationship between the class-side <keymap> defaults methods and changing shortcuts on the fly, but what seems to be missing are: * a way to register shortcuts/categories to be attached to a Morph class by default * a way to detach categories * a way to detach individual shortcuts Thanks, this is very exciting. We're *so* close to having this work... Sean -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

[Pharo-project] [update 2.0] #20195

by Marcus Denker

20195 ----- Issue 6259: DataStream is still there http://code.google.com/p/pharo/issues/detail?id=6259 Issue 4095: Suggestion: rename some methods for consistency (just example methods, no API changes) http://code.google.com/p/pharo/issues/detail?id=4095 -- Marcus Denker -- http://marcusdenker.de

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Benjamin

If I were you, I would have put all the VIM shortcut in one class, instead of putting them around but :) For the attachment, the solution could be to attach simultaneously several shortcuts category. Like that, you could add yours in a specific context, and remove them. An ugly solution right now could be to duplicate all the NautilusSourceCodeShortcuts entries, and to switch between NautilusSourceCodeShortcuts and VIMShortcuts. A kind of hack could be: AbstractNautilusUI class>>buildInsertModeKeymappingsOn: aBuilder <keymap> (KMRepository default categoryForName: #NautilusSourceCodeShortcuts) keymaps do: [:km | (aBuilder shortcut: (km name, 'VIM') asSymbol) category: VimInsertModeShortcuts default: km shortcut do: km action ]. (aBuilder shortcut: #commandMode) category: #NautilusSourceCodeShortcuts "#VimInsertModeShortcuts" default: Character escape asShortcut do: [ :target | Editor dumbbellCursor: true. target sourceTextArea changed. target sourceTextArea attachKeymapCategory: #VimCommandModeShortcuts ]. It's kind of a hack, but like that you ensure to have the same shortcuts in the midtime Ben On Jul 8, 2012, at 3:13 AM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> - how do I remove an individual shortcut or shortcut category from a >> morph? (so I can toggle the command/insert mode shortcuts) >> > > I'm having trouble toggling insert mode... Right now I have > AbstractNautilusUI class>>buildInsertModeKeymappingsOn: aBuilder > <keymap> > > (aBuilder shortcut: #commandMode) > category: #NautilusSourceCodeShortcuts "#VimInsertModeShortcuts" > default: Character escape asShortcut > do: [ :target | > Editor dumbbellCursor: true. > target sourceTextArea changed. > target sourceTextArea attachKeymapCategory: #VimCommandModeShortcuts ]. > > The problem is that: > * I think I have to put these shortcuts into #NautilusSourceCodeShortcuts to > have them load without overriding anything > * If I don't put them in their own category (i.e. #VimInsertModeShortcuts), > I don't know how to remove them when entering command mode (I only see a way > to remove whole categories) > > Guille, Ben - are those assumptions correct and how should I proceed? > > Thanks, > Sean > > -- > View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 8, 2012

Re: [Pharo-project] StartupPreferences

by Mariano Martinez Peck

On Sun, Jul 8, 2012 at 10:16 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Jul 8, 2012 at 6:17 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> Mariano, >> >> Can any of the script lookup logic from 2.0 be ported to 1.4? >> > > Migrate everything (the new logic and all the last improvements) is too > much. Mostly because I don't have time and because it is not a dead or > alive bug. In fact, it was never before and people never complained ;) > What you COULD do if you want is to just do this: > > > >> StartupPreferences doesn't seem very useful if only the image folder is >> checked, > > > Why it only searches in the image folder? > > buildActionList > > "First, we look at image folder, > then we look at preferences folder, > and finally at general preferences folder " > > ^ OrderedCollection new > add: [ self lookInImageDirectory ]; > add: [self lookInPreferencesFolder ]; > add: [self lookInGeneralPreferencesFolder ]; > yourself. > Ok, I was checking an old version of 1.4. Now I see: buildActionList "First, we look at image folder, then we look at preferences folder, and finally at general preferences folder " self flag: #todo. "I'm disabling this sequence because lookup of preferences folder is broken in windows." ^ OrderedCollection new add: [ self lookInImageDirectory ]; "add: [self lookInPreferencesFolder ]; add: [self lookInGeneralPreferencesFolder ];" yourself. so....migrate all the new version is costly. I don't have time to do it. If you want, you can just enable back for all but for windows: buildActionList "First, we look at image folder, then we look at preferences folder, and finally at general preferences folder " | directories | self flag: #todo. "I'm disabling this sequence because lookup of preferences folder is broken in windows. NOTE: this has been fixed in Pharo 2.0" directories := OrderedCollection new. directories add: [ self lookInImageDirectory ]. (OSPlatform current platformFamily = #Windows) ifFalse: [ directories add: [self lookInPreferencesFolder ]. directories add: [self lookInGeneralPreferencesFolder ]. ]. ^ directories > > > it should check there (the version that is in 1.4). The only reason this > version would stop searching in other places is if it did find something. > When it finds something, it stops searching (in 2.0 it contiues and > executes all the ones that are found). > > > given that the initial use case was for working in many fresh >> images. >> >> > +99 > > >> - S >> >> -- >> View this message in context: >> http://forum.world.st/StartupPreferences-tp4639058.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

July 8, 2012