Re: [Pharo-dev] Epicea user experience report
On Sat, Dec 24, 2016 at 2:46 AM, Martin Dias wrote: > Ben, yes, please create the issues if you want, and I will try to implement > them soon. I guess if they are mostly UI changes and categorized to "first > impression count" or something like that, they can still be included in > Pharo 6, no? > > One thing to discuss: what do you think about the fact that... > - the "Session changes" displays the changes of multiple log files in the > same list widget (silently concatenated), versus Well the biggest thing is probably that I did not realise it did this. So this is a problem for intuitive use of the tool. Actually it seems adverse to show multiple sessions where "Session Changes" implies "This Session". > - the "All changes" way of displaying, where the changes of each log file > are separated. > > That was my main reason to keep two windows by separate. I had the > impression that in some cases > - the user wants to see all changes together and he/she doesn't care in > which log file the changes are written, while in other cases > - the user wants to know the log files and see how are they connected, > because they have some meaning > What do you think of this? You are right, that is useful feature. But I keep "intuitively wanting**" to do this is to multi-select sessions in the "All changes" window. My use case is yesterday playing with sockets, the image froze half way through saving (hung at blank white window). So after killing the pharo process, the Image would not open. So before recreating the Image in PharoLauncher, I copied the ombu-sessions folder and copied into a fresh Image folder and selected each session in turn. (So btw that was a nice benefit of epicea versus the changes file needing to be kept more in sync with image file.) I only had half a dozen sessions so it wasn't too much trouble. But potentially there could be a lot more sessions and being able to do them all at once would be useful. ** i.e. I didn't learn the first time I tried this and it didn't work, and found I accidentally tried doing it a few more times after that. > BTW I don't like the file names... hints are welcome to improve it Which file names do you mean? cheers -ben > > Martin > > On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman wrote: >> >> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba wrote: >> > Hi, >> > >> > I think I would prefer to not have to think about this choice at all >> > when in the world menu level. The user interface from the Epicea window >> > already allows me to switch between current session and all sessions, and >> > usually the decision of what to look at is based on whether I find what I >> > am >> > looking for or not. So, rather then asking the user to think about it >> > upfront, I would prefer to have one command that opens the Epicea window on >> > the current session and allow the user to dive deeper. This would also >> > imply >> > that we would have only one command in the menu item. What do you think? >> >> Good point. I had a similar thought earlier. The individual Session >> Changes window is almost completely embedded in the All Sessions >> window, so the former seems superfluous. The and <+> buttons >> would need to be added to the All Sessions window, probably above the >> "sesssion" pane. >> >> >> Two additional things I think are required to facilitate this... >> 1. The left-pane of the All Sessions windows needs to update when a >> new session is created - per <+> button. >> 2. It would be useful if a new session was created "when the image >> opened" rather than when a change is made, so that it can be >> preselected in the left-side pane when a fresh image is opened. But >> the file shouldn't be created until the first change, for the case >> like a web service image being invoked multiple times a second. >> >> Also one other request, That the current-session be tagged "Current" >> rather than just "Today". >> >> I can log issues if they all sound reasonable. >> >> cheers -ben >> >> > >> >> On Dec 20, 2016, at 10:16 PM, stepharong wrote: >> >> >> >> I like the second because it associates the name with the function. >> >> >> >> Stef >> >> >> >> >> >> Hi all, >> >> >> >> One point of Ben's feedback is how Epicea code changes tool is >> >> presented in the World Menu. Below you can see the current state + 3 >> >> options >> >> to discuss it. >> >> >> >> >> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children >> >> [current state] >> >> >> >> >> >> >> >> >> >> 2. Attach purpose to the name: "Epicea Code Changes" >> >> >> >> >> >> >> >> >> >> 3. Just "Code Changes" + rephrase children: >> >> >> >> >> >> >> >> >> >> 4. Flatten >> >> >> >> >> >> >> >> >> >> >> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a >> >> description of the tool and it's model. >> >> >> >> Cheers. >> >> Martin >> >> >> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias >> >> wrote: >> >> Hello Ben, >> >> >> >> About discussion points in 2 (a, b
[Pharo-dev] 19489 Socket-GTInspector-Instance-of-LinkedList-did-not-understand-key
I've bumped into a minor glitch ticketed with the GTInspector embedded in the debugger. https://pharo.fogbugz.com/f/cases/19489 Henrik has kindly tried to reproduce it but was unable. But he is on Windows and I'm on Linux. Could someone on Linux take 10 minutes try to reproduce the following... Open fresh build 60334. Load the ST file attached to issue, then in playground, do this once... s := Server new. s start. "listens on port " and this once for each trial... socket := Socket newTCP. [ socket connectTo: NetNameResolver localHostAddress port: ; sendData: 'test'. ] ensure: [ socket closeAndDestroy ] This brings up an expected debugger (okay) "ShouldBeImplemented: #newFromStream: should have been implemented in Packet class" >From top stack select Packet class>>newFromStream: then select variable aSocketStream, then in next pane, select #isConnected, then click on [Raw] tab, and I get an error "Instance of LinkedList did not understand #key" Now a few times the error did not occur, but did >90% of the time. cheers -ben
Re: [Pharo-dev] Pharo 5 Catalog Down?
Crap, I will restart it when I arrive home :( > On 23 Dec 2016, at 22:16, Volkert wrote: > > Down > > >> On 23.12.2016 20:14, Sean P. DeNigris wrote: >> Bringing it up from the World Menu -> 503 error. Only me? >> >> macOS 10.12.1 >> Image >> - >> /Users/sean/Dynabook/Working Images/Pomodoro 5/Pomodoro 5.image >> Pharo5.0 >> Latest update: #50765 >> Unnamed >> >> Virtual Machine >> --- >> /Applications/Pharo.app/Contents/MacOS/Pharo >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> g...@github.com:pharo-project/pharo-vm.git Commit: >> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: >> GitHub >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString g...@github.com:pharo-project/pharo-vm.git Commit: >> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: >> GitHub >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 >> >> >> >> >> >> - >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Pharo-5-Catalog-Down-tp4928046.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >
Re: [Pharo-dev] Pharo 5 Catalog Down?
Down On 23.12.2016 20:14, Sean P. DeNigris wrote: Bringing it up from the World Menu -> 503 error. Only me? macOS 10.12.1 Image - /Users/sean/Dynabook/Working Images/Pomodoro 5/Pomodoro 5.image Pharo5.0 Latest update: #50765 Unnamed Virtual Machine --- /Applications/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 g...@github.com:pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString g...@github.com:pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-Catalog-Down-tp4928046.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Pharo 5 Catalog Down?
Bringing it up from the World Menu -> 503 error. Only me? macOS 10.12.1 Image - /Users/sean/Dynabook/Working Images/Pomodoro 5/Pomodoro 5.image Pharo5.0 Latest update: #50765 Unnamed Virtual Machine --- /Applications/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 g...@github.com:pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString g...@github.com:pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-Catalog-Down-tp4928046.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] MQTT for Pharo
timrowledge wrote > Hi Sven, > yes, the code in SqueakSource/MQTT is very early stuff. It's improving > quickly though. I'd be happy to get together to work on an as common as > possible versions for both Squeak and Pharo. - Cheers, Sean -- View this message in context: http://forum.world.st/MQTT-for-Pharo-tp4927759p4928045.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Epicea user experience report
Ben, yes, please create the issues if you want, and I will try to implement them soon. I guess if they are mostly UI changes and categorized to "first impression count" or something like that, they can still be included in Pharo 6, no? One thing to discuss: what do you think about the fact that... - the "Session changes" displays the changes of multiple log files in the same list widget (silently concatenated), versus - the "All changes" way of displaying, where the changes of each log file are separated. That was my main reason to keep two windows by separate. I had the impression that in some cases - the user wants to see all changes together and he/she doesn't care in which log file the changes are written, while in other cases - the user wants to know the log files and see how are they connected, because they have some meaning What do you think of this? BTW I don't like the file names... hints are welcome to improve it Martin On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman wrote: > On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba wrote: > > Hi, > > > > I think I would prefer to not have to think about this choice at all > when in the world menu level. The user interface from the Epicea window > already allows me to switch between current session and all sessions, and > usually the decision of what to look at is based on whether I find what I > am looking for or not. So, rather then asking the user to think about it > upfront, I would prefer to have one command that opens the Epicea window on > the current session and allow the user to dive deeper. This would also > imply that we would have only one command in the menu item. What do you > think? > > Good point. I had a similar thought earlier. The individual Session > Changes window is almost completely embedded in the All Sessions > window, so the former seems superfluous. The and <+> buttons > would need to be added to the All Sessions window, probably above the > "sesssion" pane. > Two additional things I think are required to facilitate this... > 1. The left-pane of the All Sessions windows needs to update when a > new session is created - per <+> button. > 2. It would be useful if a new session was created "when the image > opened" rather than when a change is made, so that it can be > preselected in the left-side pane when a fresh image is opened. But > the file shouldn't be created until the first change, for the case > like a web service image being invoked multiple times a second. > > Also one other request, That the current-session be tagged "Current" > rather than just "Today". > > I can log issues if they all sound reasonable. > > cheers -ben > > > > >> On Dec 20, 2016, at 10:16 PM, stepharong wrote: > >> > >> I like the second because it associates the name with the function. > >> > >> Stef > >> > >> > >> Hi all, > >> > >> One point of Ben's feedback is how Epicea code changes tool is > presented in the World Menu. Below you can see the current state + 3 > options to discuss it. > >> > >> > >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children > [current state] > >> > >> > >> > >> > >> 2. Attach purpose to the name: "Epicea Code Changes" > >> > >> > >> > >> > >> 3. Just "Code Changes" + rephrase children: > >> > >> > >> > >> > >> 4. Flatten > >> > >> > >> > >> > >> > >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a > description of the tool and it's model. > >> > >> Cheers. > >> Martin > >> > >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias > wrote: > >> Hello Ben, > >> > >> About discussion points in 2 (a, b and c): I agree with your > arguments... somebody that just moved from Pharo 5 to 6 and crashed an > image will look for a "Recover lost changes" in the menu and can have a > problem to discover it the replacement in a World->Tools->Epicea->... entry. > >> > >> Then, as a first step we could flatten the 2 menu entries and then at > least anybody will easily find an entry related to changes in World->Tools. > >> > >> Second, we could try to merge both Epicea GUIs into one (suggestions > are welcome). > >> > >> I still have to read more in detail the remaining of your report to > answer. Anyway, thanks a lot for it. > >> > >> Cheers, > >> Martin > >> > >> > >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman wrote: > >> 1. Created fresh Pharo image (build 60269) > >> > >> > >> 2. Opened World > Tools > Epicea > All changes > >> > >> Points for discussion... > >> > >> a. How many submenu items are expected for Epicea? Can we push the > >> current ones up so the Tools menu remains a flat menu. > >> > >> b. Do we need the two current menu items? "Current session" is > >> encompassed by "All changes"? What expectations do people have of how > >> often they'll use the former rather than the latter? > >> > >> c. When people move from Pharo 5 to Pharo 6 and in a panic want to > >> "recover changes" for a crashed image, they'll be looking for that > >> familiar feature name, not a new app name.
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
On Fri, Dec 23, 2016 at 9:27 PM, Denis Kudriashov wrote: > Hi. > > I always catch myself that I am completely lost in method versions (and > feel pain :)). > There is no clue what at the left pane and what at the right pane. > > Now I realize that VersionBrowser is trying to compare selected version > versus next version (according to list order). > So right pane shows selected version and left pane shows next one. > For me all of these is super non intuitive but maybe it is only my > problem. So here I want to ask about your experience. Do you feel same? > > I would prefer if VersionBrowser will always compare selected version > versus current version in image with actual image version on the left and > selected version on the right. > > What you think? > Thanks for bringing this up. I often find it awkward and non-intuitive, but have lived with it. Your idea to keep the left had code permanently the current-version would definitely make it more intuitive, but just another idea... In the bottom panes, both "side-by-side" and "diff", there is green & red highlighting. What about using the same highlight colours in the top pane to show which "version" the coloured code relates to. So for example, when opened, in the top pane the first line as the current-version would be highlighted green, as would the left pane. The second line would be highlighted red as the most recent previous-version, as would the right-pane. Now selecting an item in the top-pane moves the red highlight and changes the right-pane - which would effectively per Denis' proposal. But you might also ctrl-click in the top pane to move the green-highlight which changes the left-pane. Then perhaps "Revert" should not be a menu item in the top-pane (since there are two selections), but should have Revert menu item in both left-pane and right-pane. cheers -ben
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
Le 23/12/2016 à 16:16, Denis Kudriashov a écrit : 2016-12-23 16:04 GMT+01:00 Thierry Goubier mailto:thierry.goub...@gmail.com>>: In short, what you describe replaces a non-obvious, arbitrary pane allocation by another one... maybe just more familiar to you. No. I suggest current image version on left pane with visible label "current version". And selected version on the right pane. Also when you will switch from one version to another left pane will be never changed which will be visible and intuitive indication that new selected method is on the right pane because only right pane will change. Given that you're already watching the method in the image (because you selected it in Nautilus before calling versions), a simpler display is just a single pane showing the old version code with removal and additions / changes markers. Note: intuitive is a bad word for UI design. Nothing in UI is "intuitive". Learned / Familiar / has visible feedback / respect common ui guidelines are correct values. Thierry
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
Le 23/12/2016 à 18:13, Nicolas Passerini a écrit : I agree, current version is not intuitive. I'd like to see someone come with an idea that covers both uses of the version browser: 1- Revert to a previous version of a method 2- Study and compare the various changes the method went through Denis wants 1-. Current version browser focuses on 2- in a rather uintuitive way, especially if you are trying to do 1-. Moreover, is it possible to consider a design that could allow Iceberg or other tools to contribute older versions from repository? This one is easy and has been working for GitFileTree for a long time already. Technically, a few years ago, the version browser was rewritten to use Ring as its underlying code model; filling the version browser with RGMethodDefinition(s) allow you to use any source for past versions of a method. The API in gitfiletree is: MCFileTreeGitRepository>>#gitVersionsForDefinition:in: And you just need to change a single line in the version browser, as in: AltVersionBrowser>>#buildChangeList[2](*) Regards, Thierry [1] https://github.com/dalehenrich/filetree/blob/pharo6.0_dev/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/instance/gitVersionsForDefinition.in..st [2] https://github.com/ThierryGoubier/AltBrowser/blob/pharo6/Alt-Browser.package/AltVersionBrowser.class/instance/buildChangeList.st 2016-12-23 16:16 GMT+01:00 Denis Kudriashov mailto:dionisi...@gmail.com>>: 2016-12-23 16:04 GMT+01:00 Thierry Goubier mailto:thierry.goub...@gmail.com>>: In short, what you describe replaces a non-obvious, arbitrary pane allocation by another one... maybe just more familiar to you. No. I suggest current image version on left pane with visible label "current version". And selected version on the right pane. Also when you will switch from one version to another left pane will be never changed which will be visible and intuitive indication that new selected method is on the right pane because only right pane will change.
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
2016-12-23 18:30 GMT+01:00 Denis Kudriashov : > Moreover, is it possible to consider a design that could allow Iceberg or >> other tools to contribute older versions from repository? > > > I don't know. I not look into code But we of course need to improve it for upcoming git integration
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
2016-12-23 18:13 GMT+01:00 Nicolas Passerini : > Moreover, is it possible to consider a design that could allow Iceberg or > other tools to contribute older versions from repository? I don't know. I not look into code
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
I agree, current version is not intuitive. Moreover, is it possible to consider a design that could allow Iceberg or other tools to contribute older versions from repository? 2016-12-23 16:16 GMT+01:00 Denis Kudriashov : > > 2016-12-23 16:04 GMT+01:00 Thierry Goubier : > >> >> In short, what you describe replaces a non-obvious, arbitrary pane >> allocation by another one... maybe just more familiar to you. > > > No. I suggest current image version on left pane with visible label > "current version". And selected version on the right pane. > Also when you will switch from one version to another left pane will be > never changed which will be visible and intuitive indication that new > selected method is on the right pane because only right pane will change. >
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
2016-12-23 16:04 GMT+01:00 Thierry Goubier : > > In short, what you describe replaces a non-obvious, arbitrary pane > allocation by another one... maybe just more familiar to you. No. I suggest current image version on left pane with visible label "current version". And selected version on the right pane. Also when you will switch from one version to another left pane will be never changed which will be visible and intuitive indication that new selected method is on the right pane because only right pane will change.
Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
Hi igor Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago was working on it during 1,5 years. Noury Bouraqadi Luc Fabresse Stef On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko wrote: Hi, i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) i'm interested in any bits, starting from basic ones, since i'm gonna to work with it in closest future, so would be nice to use Pharo & stand on a shoulders of others, of course, to learn it fester and understand it better. --Best regards, Igor Stasenko. -- Using Opera's mail client: http://www.opera.com/mail/
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
On Fri, 23 Dec 2016 16:04:45 +0100, Thierry Goubier wrote: Le 23/12/2016 à 14:27, Denis Kudriashov a écrit : Hi. I always catch myself that I am completely lost in method versions (and feel pain :)). There is no clue what at the left pane and what at the right pane. Agreed. I often revert to a wrong version... me too :) Now I realize that VersionBrowser is trying to compare selected version versus next version (according to list order). So right pane shows selected version and left pane shows next one. For me all of these is super non intuitive but maybe it is only my problem. So here I want to ask about your experience. Do you feel same? I would prefer if VersionBrowser will always compare selected version versus current version in image with actual image version on the left and selected version on the right. Any solution which doesn't require me to guess which pane relate to what I want to revert to has my vote. In short, what you describe replaces a non-obvious, arbitrary pane allocation by another one... maybe just more familiar to you. What you think? That you are suggesting a solution which is maybe a bit more intuitive for you, but not that intuitive. Regards, Thierry Best regards, Denis -- Using Opera's mail client: http://www.opera.com/mail/
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
Le 23/12/2016 à 14:27, Denis Kudriashov a écrit : Hi. I always catch myself that I am completely lost in method versions (and feel pain :)). There is no clue what at the left pane and what at the right pane. Agreed. I often revert to a wrong version... Now I realize that VersionBrowser is trying to compare selected version versus next version (according to list order). So right pane shows selected version and left pane shows next one. For me all of these is super non intuitive but maybe it is only my problem. So here I want to ask about your experience. Do you feel same? I would prefer if VersionBrowser will always compare selected version versus current version in image with actual image version on the left and selected version on the right. Any solution which doesn't require me to guess which pane relate to what I want to revert to has my vote. In short, what you describe replaces a non-obvious, arbitrary pane allocation by another one... maybe just more familiar to you. What you think? That you are suggesting a solution which is maybe a bit more intuitive for you, but not that intuitive. Regards, Thierry Best regards, Denis
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
2016-12-23 14:34 GMT+01:00 Nicolai Hess : > But you can always select a version an choose > compare with current > from the context menu. > Ok. Does not know about it :). Now I tried it and it not helps me a lot. It opens new window without any way to revert changes (or others) and without any clue who is who (no label what is left and what is right) And when I closed it I was again lost in versions list. Also there is menu item "Compare to version" with same no clue window. Really this menu is useless. VersionBrowser should just also multi selection to show difference between selected versions. And by default it should compare to current one.
[Pharo-dev] [ANN] Pharo Sprint First half 2017
Hi, As this year, there will be again “Pharo Sprints” next year. At these dates we meet (virtual or real) to work on boring (or complex) issues together: Jan 27 Mar 3 Mar 31 Apr 28 May 26 Jun 30 Local sprints: - University of Chile (DCC). Not January, but likely the other dates - Inria Lille: All - Remote: All. We will try to improve remote sprint experience next year! - The sprints will be added to https://association.pharo.org/events Marcus
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
Am 23.12.2016 2:28 nachm. schrieb "Denis Kudriashov" : Hi. I always catch myself that I am completely lost in method versions (and feel pain :)). There is no clue what at the left pane and what at the right pane. Now I realize that VersionBrowser is trying to compare selected version versus next version (according to list order). So right pane shows selected version and left pane shows next one. For me all of these is super non intuitive but maybe it is only my problem. So here I want to ask about your experience. Do you feel same? I would prefer if VersionBrowser will always compare selected version versus current version in image with actual image version on the left and selected version on the right. What you think? Best regards, Denis But you can always select a version an choose compare with current from the context menu.
Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?
2016-12-23 14:27 GMT+01:00 Denis Kudriashov : > I would prefer if VersionBrowser will always compare selected version > versus current version in image with actual image version on the left and > selected version on the right. > Also I think it is better to not show current method in versions list. I am very often revert it instead of real previous version. It's super annoying.
[Pharo-dev] Do you think VersionBrowser is counterintuitive?
Hi. I always catch myself that I am completely lost in method versions (and feel pain :)). There is no clue what at the left pane and what at the right pane. Now I realize that VersionBrowser is trying to compare selected version versus next version (according to list order). So right pane shows selected version and left pane shows next one. For me all of these is super non intuitive but maybe it is only my problem. So here I want to ask about your experience. Do you feel same? I would prefer if VersionBrowser will always compare selected version versus current version in image with actual image version on the left and selected version on the right. What you think? Best regards, Denis
Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?
Thanks for the update - that is exciting and gives me some hope. What do we need to do to help bloc advance at pace? Tim Sent from my iPhone > On 23 Dec 2016, at 01:22, Yuriy Tymchuk wrote: > > Hi Tim, > > it’s coming, but it needs some time: > https://twitter.com/aliakseisyrel/status/812065956856025088 > >> On 1 Dec 2016, at 14:44, Tim Mackinnon wrote: >> >> To give people a better view of this - here is the Pharo image next to the >> mail client (I’m not sure if the screen captures really do it justice as >> when you scale them down in a picture everything looks fine - however if I >> zoom into that bottom corner in a second image it might make it more >> obvious). >> >> I think this has been a problem brewing for a while, but if most >> contributors don’t have retina screens (although they are getting much more >> common now) then I guess it goes unnoticed. I suspect in the next few years, >> as people start replacing machines - it will gain more visibility. >> >> I find it quite distracting when switching from mail or other apps to Pharo >> and then you notice the fuzziness. Maybe if you spend a few hours in the >> code you might adjust. >> >> Tim >> >> >> >> The following is the bottom corner zoom in to show what I mean by fuzzy: >> >> >> >>> On 30 Nov 2016, at 23:53, Stephan Eggermont wrote: >>> On 30/11/16 20:32, Sven Van Caekenberghe wrote: Maybe, but the thing is, you are looking at it half size, in some sense, when it is on a Retina display. Anyway, to me, it is OK, but my eyes are no longer what they used to be. I can imagine young people being more sensitive to it. >>> >>> Nah, it just is blurry. I've played a bit with krono's vm, and it is >>> a very noticable difference. Much better readable and less tiring. >>> And you mostly only notice when trying to go back from HiDPI to low. >>> >>> Stephan >
