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

Re: [Pharo-users] Alt-tab between windows

by Esteban Lorenzano

ah, couple of things more (out of ps :P) I do believe Spotter will play a fundamental role in the enhancement of our IDE, but I was also thinking on some kind of âemacs style menusâ, in the sense of some guiding menus that you open with a key and you have an idea of which options you look. This could also be something integrated in the spotter in the way unity of ubuntu is going (you type âsaveâ and you have the options, etc.) Anywayâ¦ nothing that I found the time to test for the moment, but I will. And none of this options will heal our âwindowitisâ deceaseâ¦ and honestly I do not have any idea how we can enhance that. To hide infinite windows into infinite tabs (or buffers) does not feels like the correct solution for me (I remember beck in my java days, I sually kept more than 20 tabs open all the timeâ¦ same with browsers here in pharo, but now I also open inspectors, playgrounds and debuggersâ¦ soâ¦ is a complicated issue). Or maybe Iâm wrong, and maybe just reducing the visual contamination is already a big step forwardâ¦ who knows. Actually, we will not know until we try itâ¦ just saying ânoâ is not a very constructive opinion. But in that case, the question is âwho will bell the catâ :) Esteban > On 19 May 2015, at 19:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 19 May 2015, at 16:51, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> 2015-05-19 11:41 GMT-03:00 Avdi Grimm <avdi(a)avdi.org>: >>> It took thousands of programmers decades of work in many different languages >>> to create this variety. I'd hate to see the smaller Pharo community pour >>> tons of effort into re-inventing these solutions. >>> >>> Which is why I'm suggesting that it may be more helpful to re-frame the >>> problem. General purpose window management is a problem that has been solved >>> many times over. Do you really want to do it yet again? I suspect that with >>> some careful examination of Pharo coding workflows, you could find a way to >>> obviate the need for zillions of windows, and solve a simpler problem >>> instead. >> >> +1 > > +1 > > Esteban > > ps: (and two Estebanâs counts exponentially :P) > pps: but there are also other problems to take into account, and thatâs also community culture. I know many people finds the amount of windows opened somekind stressing when they arrive to our little worldâ¦ but it actually fits a purpose and change it to other solutions just because âeverybody else does itâ can probably do not work. A suitable solution for LISP does not need to be a suitable solution to Pharo, just out of the box. Which of course does not means I would not want to explore more efficient workflows. > ppps: And of course, there is the effort that starting in other direction goesâ¦ even copying an existing IDE workflow would be a lot of work for us, so sometimes is better just to incrementally enhance, even if that means we will keep some metaphors during more time than desired. > pppps: as I always say in this list, human-computer interaction is not an easy field and is very studied, so is not easily solvable with our always subjective opinion. In that sense, I completely share the feeling that we need to keep studying and experimenting with other communities experiences until we find something that we can reengineer into something we need/want. > ppppps: I ran out of âpsâ, but I couldnât resist to put five âp" in a line :) > >> >> Esteban A. Maringolo

May 19, 2015

Re: [Pharo-users] Spec - Columns Containing Rows Containing Columns

by Peter UhnÃ¡k

Indeed using a single top level container should be the best approach, because "SpecLayout composed" doesn't have any layout - so adding multiple items into it are just placed one over the other. Arguably it might be better to add new methods "SpecLayout rows/SpecLayout cols" or something like that so you have the base layout defined. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ view := DynamicComposableModel new. models := #( leftCol LabelModel t11 LabelModel t12 LabelModel t13 LabelModel t21 LabelModel t22 LabelModel t23 LabelModel ). view instantiateModels: models. models pairsDo: [ :lbl :m | (view perform: lbl asSymbol) label: lbl. ]. layout := SpecLayout composed newRow: [ :r | r newColumn: [ :col | col add: #leftCol ]. r newColumn: [ :col | col newRow: [ :row | row add: #t11; add: #t12; add: #t13 ]; newRow: [ :row | row add: #t21; add: #t22; add: #t23 ] ] ]; yourself. view openWithSpecLayout: layout. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter On Tue, May 19, 2015 at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-05-19 14:34 GMT+02:00 Craig Johnson <craig(a)hivemind.net>: > >> Hi, >> >> Spec has me tearing my hair out again. >> >> I'm using a composed layout with two columns in it. In the second column >> I'd like to place some rows which in turn contain columns. >> >> There does not seem to be any way to do this. Everthing that I try only >> renders one of the two main columns. >> Guidance would be spreciated. >> > > > I don't know for sure, but I had a similar issue and solved it by using a > single toplevel container > (only one call newRow/newColumn after "SpecLayout composed") > > ^ SpecLayout composed > newRow:[ :top | > > top > newColumn: [ :tcol | > tcol newRow:[:trow | trow add: #lblFolder ] height: 30. > ]; > > newColumn: [ :tcol | > tcol newRow:[:trow | > trow newColumn: [ :tcol2 | tcol2 add: #ddlfolder]; > newColumn: [ :tcol2 | tcol2 add: #txtFolder]. > ] height: 30. > ]. > ] > > > >> >> defaultSpec >> <spec: #default> >> >> ^SpecLayout composed >> newColumn: [ :tcol | >> tcol newRow:[:trow | trow add: #lblFolder ] height: 30. >> ]; >> >> newColumn: [ :tcol | >> tcol newRow:[:trow | >> trow newColumn: [ :tcol2 | tcol2 add: #ddlfolder]; >> newColumn: [ :tcol2 | tcol2 add: #txtFolder]. >> ] height: 30. >> ]. >> > >

May 19, 2015

Re: [Pharo-users] Garage and SQLite file databases, general project structure

by Ben Coman

On Tue, May 19, 2015 at 10:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > I made the following commits: > This does not change the current default behaviour, but it makes it a lot > easier to work with relative references: > Cool. Now just a passing thought. The original term URL is from RFC1738, which is obsolete. RFC3986 says "The term 'Uniform Resource Locator' (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism." I don't completely follow that, but maybe there is use for a ZnUri class that provides broader semantics than ZnUrl. > ZnUrl image + 'foo.txt' > > => "file:///Users/sven/Develop/Smalltalk/foo.txt" > > You just have to choose an appropriate base URL: > > 'postgresql://user:password@localhost:5432/default' asUrl + 'test' > > => "postgresql://user:password@localhost:5432/test" > > However, when you override the host, the port (actually the whole > authority) is reset as well (according to my interpretation of the RFC > anyway), that is why I added #portIfAbsent: > > 'postgresql://production/user-db' asUrl portIfAbsent: 5432 > > => 5432 > > I also added #asFileUrl to help in the common case of interpreting any > scheme as referring to a file path. After that conversion, one will > probably want to do an #asFileReference. > > > Looking through Zinc I notice that the schemes are symbols. Any plans > to make these classes? To maybe(?) make it easier to extend to other > schemes (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) > ? Or do you consider that outside the scope of Zinc ? > > Well, it is a 'problem area' (design/implementation wise). Your suggestion > makes sense though: to make the schemes objects so that they could > implement specific behaviour (rather than making many subclasses of ZnUrl). > I will think about this, thanks for the idea ! > > > Perhaps an advantage of a Scheme class is that it might make it easier for a "postgresql" to define a default port. btw, The part of RFC3986 that sparked this thought was this... "URI scheme specifications can define opaque identifiers by disallowing use of slash characters, question mark characters, and the URIs "scheme:." and "scheme:..". cheers -ben

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Esteban Lorenzano

> On 19 May 2015, at 16:51, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-05-19 11:41 GMT-03:00 Avdi Grimm <avdi(a)avdi.org>: >> It took thousands of programmers decades of work in many different languages >> to create this variety. I'd hate to see the smaller Pharo community pour >> tons of effort into re-inventing these solutions. >> >> Which is why I'm suggesting that it may be more helpful to re-frame the >> problem. General purpose window management is a problem that has been solved >> many times over. Do you really want to do it yet again? I suspect that with >> some careful examination of Pharo coding workflows, you could find a way to >> obviate the need for zillions of windows, and solve a simpler problem >> instead. > > +1 +1 Esteban ps: (and two Estebanâs counts exponentially :P) pps: but there are also other problems to take into account, and thatâs also community culture. I know many people finds the amount of windows opened somekind stressing when they arrive to our little worldâ¦ but it actually fits a purpose and change it to other solutions just because âeverybody else does itâ can probably do not work. A suitable solution for LISP does not need to be a suitable solution to Pharo, just out of the box. Which of course does not means I would not want to explore more efficient workflows. ppps: And of course, there is the effort that starting in other direction goesâ¦ even copying an existing IDE workflow would be a lot of work for us, so sometimes is better just to incrementally enhance, even if that means we will keep some metaphors during more time than desired. pppps: as I always say in this list, human-computer interaction is not an easy field and is very studied, so is not easily solvable with our always subjective opinion. In that sense, I completely share the feeling that we need to keep studying and experimenting with other communities experiences until we find something that we can reengineer into something we need/want. ppppps: I ran out of âpsâ, but I couldnât resist to put five âp" in a line :) > > Esteban A. Maringolo >

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Ben Coman

On Tue, May 19, 2015 at 10:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, May 16, 2015 at 5:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> my answer on stackoverflow: >> >> well... you hit one of our weaker spots :) >> >> Keybindings are not in his best shape, but: >> >> - Actually, alt+tab is already set to "switch window" activity. The >> problem is that does not work all the time (for example, it does not work >> on Playground). >> - This is because there are some hardcoded logic there, who we are >> removing slowly from the system (some of those parts have more than 15yrs >> since they come from before Pharo has born). >> - Someone (probably in a failed attempt to fix the playground, or the >> hardcodes) forget a halt in the method who creates a new preview window... >> so even if you reach that part of the system, you will have a debugger. Of >> course, you will be able to restore correct behaviour by just removing the >> breakpoint, but that will not correct the fact "switch windows" will not be >> available everywhere. >> - I opened a bug entry for it: https://pharo.fogbugz.com/f/cases/15546, >> in case you want to follow the issue (you will need an account there, I'm >> sorry for that). >> >> In any case, we are moving out this hardcode stuff, and you can check all >> currently available settings going to **World Menu/System/Keymap Browser** >> (they are a lot, we are also playing with ideas on how to show better this >> combinations... emacs style, popup notifications, etc.) >> >> Esteban >> >> ps: I will like to have a solution for this, if anyone can help a bit in >> this areaâ¦ but it has to be a solution using the keybindings framework. I >> will deny integration to any hardcoded solution :) >> > > I thought I'd have a look at this (a reason to dip my toe into the > keybindings framework for the first time). Not sure if I'm heading down the > right track, but the first part of just responding to key presses was much > easier than I thought it might be, so I thought there might be general > interest. > Here it is fully working. Note the correction moving #isGlobal to the class-side. > > > KMCategory subclass: #TaskListGlobalShortcut > instanceVariableNames: '' > classVariableNames: '' > category: 'Morphic-Widgets-Taskbar' > > TaskListGlobalShortcut class >> isGlobalCategory "<---whoops, > correction" > ^true > > I discovered that to match existing method names, #selectNextTask was better than #cycleLeft. TaskListGlobalShortcut>>selectNextTask <shortcut> ^ KMKeymap shortcut: $] command action: [ World taskList selectNextTask. ] TaskListGlobalShortcut>>selectPreviousTask <shortcut> ^ KMKeymap shortcut: $[ command action: [ World taskList selectPreviousTask. ] NullTaskList>>selectNextTask self openTaskList selectNextTask NullTaskList>>selectPreviousTask self openTaskList selectPreviousTask NullTaskList>>openTaskList ^ world theme openTaskListIn: world. " Adapted from NullTaskList >> handleEvent: " UITheme>>openTaskListIn: worldMorph | taskListMorph | taskListMorph := TaskListMorph new. taskListMorph openAsIsIn: worldMorph. ^ taskListMorph "Adapted from UITheme >> openTaskListIn:from: " KMRepository reset. This was developed on Pharo 4, but I uploaded SLICE-Issue-15546-alttab-does-not-work-correctly-BenComan.2 to Pharo5Inbox per policy to integrate there first. I guess since this is not mission critical it might be queued for a while for Pharo 4. Nicolai, I didn't see your slice until after. I've left some comments on fogbugz comparing the both slices. cheers -ben

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Dimitris Chloupis

No reason to be offended. I am merely stated my opinion on the subject , obviously personal taste plays a role . I never said your experiences are invalid, I can assure you if that was my intention you will be clearly reading it inside my text. Afterall I was the one that recommended you in IRC to bring this discussion about Alt+TAB in the mailing list to find a solution to your problem. I do however disagree with the idea that emacs has a good interface and I am far from the only one. Again we come down to personal opinion. But of course you are welcome to disagree, I have no problem with that nor I am here to convince people that my opinion is valid and their own is invalid. I am familiar with some of the features you described as I already said , I am an emacs users for quite some time now. Not an emacs power user , just a guy that loves to use emacs from time to time. Because of the opinion I have expressed, I try to keep as few windows or buffers open as possible. The remark on shortcuts is not just ranting, I use Blender for 3d graphics on daily basis and shortcuts have become a serious issue. The application has grown so large that is unmaintainable to demand from user to memorise 1000 shortcuts so there is a very active discussion between Blender developers how to deal with this problem. A recent addition was pie menus, right click menus that use mouse gestures to navigate as quickly as a shortcut but with no demand on memorization. Its not an easy problem to solve by any means, so yes when you said that emacs has solved it, I have to confess I wished that it was that easy for me . But I do value your opinion and your experience even If I disagree. Its important to have such discussion , if people say "emacs way of doing things is great" then so be it. Let's copy these Emacs features right away, I am all for it. Pharo is not just for me, but for all of us. I do also want more people to use Pharo and find it more user friendly. On Tue, May 19, 2015 at 6:28 PM, Avdi Grimm <avdi(a)avdi.org> wrote: > > On Tue, May 19, 2015 at 11:14 AM, Dimitris Chloupis <kilon.alios(a)gmail.com > > wrote: > >> The shortcut based interface has been tried and has failed. >> > > >> The thought that I need to search for a buffer, setup buffer groups , >> create tabs , use a weird complex shortcut etc when I just can use my mouse >> and in one second click the window I want is a no brainer for me. Its not >> just simple , its better. >> > > You clearly have different tastes than mine, and that's fine. However, if > you're going to deal with that by saying that my experiences are invalid, > and compound it by talking about things you clearly haven't actually tried > (what does "create tabs" or "setup buffer groups" even mean?) I'm not going > to bother responding to you anymore. >

May 19, 2015

Spec TreeModel dynamic contents

by webwarrior

I want to make a tree using TreeModel that reacts to changes in underlying data - when an item changes, tree node for that item should update its state (recompute its children, etc.). Rebuilding the whole tree is ok, as long as selections and collapsed/expanded state of nodes are preserved. Using #updateTree however resets all these things. And there is no easy way to save/load them either - #selectedItems/#selectedItems: work with TreeNode instances that get reset, and collapsed/expanded states of nodes are simply unaccessible from TreeModel. I also tried subclassing TreeNodeModel. But I found no way to update underlying UI widget. There is a huge mess involving TreeNodeModel, MorphicTreeNodeAdapter, SpecTreeNodeModel, and MorphTreeNodeMorph. The only option left is to extract all needed information from TreeNodeModel hierarchy (preserving the tree structure) before update, and then try to reapply it to newly created hierarchy. Or is there an easier way? -- View this message in context: http://forum.world.st/Spec-TreeModel-dynamic-contents-tp4827440.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Avdi Grimm

On Tue, May 19, 2015 at 11:14 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > The shortcut based interface has been tried and has failed. > > The thought that I need to search for a buffer, setup buffer groups , > create tabs , use a weird complex shortcut etc when I just can use my mouse > and in one second click the window I want is a no brainer for me. Its not > just simple , its better. > You clearly have different tastes than mine, and that's fine. However, if you're going to deal with that by saying that my experiences are invalid, and compound it by talking about things you clearly haven't actually tried (what does "create tabs" or "setup buffer groups" even mean?) I'm not going to bother responding to you anymore.

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Dimitris Chloupis

The shortcut based interface has been tried and has failed. It works well for medium size complexity but to rely the whole functionality of a very complex application to shortcuts is not anything shorter than insane. So shortcuts are without any doubt useful and should be used by all apps but they can go so far. Add to that the emacs shortctus are mess , a huge mess. Many of them make zero logical sense with some really weird keyboard combinations. Emacs has not solve the problem of UI it has made severely worse and the same story goes for Vim. Both projects rely on the obsession of coders with relying on command line interfaces. Command line are of course much simpler to customise and produce but design wise they come with some inherit weakness. The thought that I need to search for a buffer, setup buffer groups , create tabs , use a weird complex shortcut etc when I just can use my mouse and in one second click the window I want is a no brainer for me. Its not just simple , its better. Bare in mind, I come from Emacs, actually it was Emacs people (at #emacs in irc) that introduced me to squeak and then to pharo. Without emacs I would not be here . I still use #emacs to edit files because is such a great editor. I love emacs . But a good UI ? Nope, definitely not in my book. Actually Emacs for me is proof why text based UIs will never be able to compete with GUIs because emacs is one of the best and still very difficult to use. Do I want some of the emacs buffer management tools in Pharo ? Sure Will they improve the workflow ? Absolutely Will they solve the problem ? Nope I think Spotter can play a very good role in the management of windows to implement functionality similar to Emacs. But no I wont trade the Pharo mess for the Emacs mess not even in a 1 million years. I was raised with text based interfaces and command lines since 1988 and I always had and will forever hate them. For me at least the future is AI GUIs , GUIs that watch user actions , understand his habbits and automate the workflow with minimum amount of manual customization. There was a tool once promoted here that watched the usage of windows and the ones least used were closed which I think is a step towards the right direction but its definitely a very long road ahead. On Tue, May 19, 2015 at 5:42 PM Avdi Grimm <avdi(a)avdi.org> wrote: > On Tue, May 19, 2015 at 3:53 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> >> >> About general GUI and UI designs its not any less nightmarish to open >> multiple windows in Pharo than it is to open multiple buffers in emacs. The >> diffirence between the two is that with emacs you have the nightmare of >> lack of any GUI while in pharo you have the lack of sophisticated editing. >> > > > With respect, this is manifestly untrue. Buffer management is a solved > problem in Emacs. In fact, it's been solved and re-solved many times over, > to the point where it can suit anyone's tastes. Whether you want: > > * To simply toggle between the last few buffers > * To list, sort, and filter buffers quickly until you find the one you want > * To do fuzzy-completed searches on buffers > * To manage buffers in tabs and tab groups > * To have sidebars listing open buffers > * To kill or operate on many buffers at once based on what project they > are in or some other criteria > * To have a fully window-managed interface that can save, reload, and > switch between different window configurations for different contexts at a > keypress > * To forget about buffers completely, and just navigate to the thing you > want to see (and let Emacs worry about what buffers happen to be in memory) > > (And lest anyone say that buffer management is a different problem from > window management, remember that Emacs is an application environment, and > that a "buffer" may be a full application window, such as an IRC channel or > even a Smalltalk-style browser.) > > Whether you want any of these features or many others, there are mature > and well-tests solutions for all of them. Whereas as many longtime users > have confirmed in this thread, Smalltalk environments don't even have the > window management to match the Emacs built-in features, let alone the > mature extension ecosystem. > > I made my original seven-minute Pharo video with the intent of getting > traditionally IDE-averse Ruby programmers to realize some of the things > they are missing. It's way too easy to say "oh, no one else has solved > this any better". And as a result, a number of people said "wow, I usually > hate IDEs but I need to check this out". But this cuts both ways. > > >> Pharo is doing some good work on this area but realistically , the >> community is too small to solve such a huge problem even with pharo ease of >> use. >> > > > This I agree with completely. > > My favorite OS for programming is Linux. In linux, window management is a > problem that has been solved many times over. There are dozens of window > managers (hundreds, if you count inactive projects). There are high-tech > compositing window managers that can do MacOS-style Expose zoom-out for > quickly locating windows. There are WMs that rigidly control where windows > show up, based on a policy you decide. There are all kinds of different > aids for quickly listing and navigating between windows. > > It took thousands of programmers decades of work in many different > languages to create this variety. I'd hate to see the smaller Pharo > community pour tons of effort into re-inventing these solutions. > > Which is why I'm suggesting that it may be more helpful to re-frame the > problem. General purpose window management is a problem that has been > solved many times over. Do you really want to do it yet again? I suspect > that with some careful examination of Pharo coding workflows, you could > find a way to obviate the need for zillions of windows, and solve a simpler > problem instead. > > >

May 19, 2015

[Pre-ANN][Job] We are looking for a "Engineer R&D"

by Marcus Denker

Hi, We will put the official announce online later this weekâ¦ we are looking to fill a a âyoung engineer positionâ. This is for recent graduates who finished their degree 2013/2014/2015. The topic is to work for 2 years on improving âremoteâ debugging for cases like server deployment, typical cloud scenarios and when using embedded Pharo images (e.g. for robotics). If you are interested (or know someone who might), please contact me. (official announcement will be online later this week). Marcus

May 19, 2015