Playground and its current usability in Pharo4.0 Latest update: #40307
While I like that GTTools are in Pharo 4 now (thanks!!!) and allow all kind of neat things I basically ask myself if we forgot to remember usability on a few places: 1. the world menu item "Workspace" opens a window "Playground" including also a tab with the same name "Playground". => CONFUSING I would suggest that we rename the window "Workspace" and keep "Playground" for the initial tab. This is easy to fix and would also fulfill the expectation when a beginner grabbed an existing Smalltalk or Pharo book. 2. While in all UI interfaces (Windows, Linux, Mac) the order in the context menu is "Cut", "Copy", "Paste" the playground menu uses a different order "Copy", "Cut" "Paste". => CONFUSING again I would suggest to use the well known order "Cut","Copy","Paste". 3. When one uses "Inspect it" from the context menu it means - to run the code - and the resulting object is then "inspectable" in a new window On the other side "Do it and go" from the context menu means - to run the code - and the resulting object is then "inspectable" in a new pane (but same window) The intention of both menu items and also the result is the same, but the naming is different ("go" vs. "inspect"). But the only notable difference is that in one case the inspectable object is opening right to the existing pane in the other case a new window is opened. => CONFUSING and inconsistent This is harder to solve. Possible solutions are: 3a. We keep the "inspect" concept and name the menu items "Do and Inspect it" and "Inspect in new window" 3b. We keep "Do it" as before to run the code, also "Inspect it" which opens the new pane to the left in the same window. If someone wants to open a new inspector window he should keep SHIFT key pressed while running "Inspect it". This is a concept known from web browsers and other tools today, clicking on a link while pressing SHIFT opens a new window. 4. The icons in the context menu of Playground are not the same as the ones in the Pharo browsers. => CONFUSING and inconsistent They are just black and if one switches to the Pharo dark theme they stay black and therefore looking ugly and make nearly no sense on the dark grey menu background. For now we should use the known icons that we already have. Maybe currently they are hardcoded and may conflict with Moose vs. Pharo icons - but this could be solved with the Icon Theming. (In the long term I would like to see scalable icons in Pharo menues (instead of bitmaps) similar to "Fontawesome" in web browsers (two colors) or SVG based ones (more colors) as currently the icon does not scale when changing the menue font size). Sorry if it sound like a rant - but the intention of this mail is that we discuss (and hopefully fix) in order to improve. Maybe it is written too early after the initial integration, but I think the mentioned points should be easy to address. Unfortunately I'm additionally confused with the changed contribution process that has exceptions for specific packages like GT to fix it myself with the usualy bugs/slice cycle. Thanks T.
Hi Torsten, Thanks for the feedback. On Thu, Oct 16, 2014 at 11:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
While I like that GTTools are in Pharo 4 now (thanks!!!) and allow all kind of neat things I basically ask myself if we forgot to remember usability on a few places:
1. the world menu item "Workspace" opens a window "Playground" including also a tab with the same name "Playground". => CONFUSING
I would suggest that we rename the window "Workspace" and keep "Playground" for the initial tab. This is easy to fix and would also fulfill the expectation when a beginner grabbed an existing Smalltalk or Pharo book.
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is that the Playground is such a distinct departure from the Workspace that it deserves a different name.
2. While in all UI interfaces (Windows, Linux, Mac) the order in the context menu is "Cut", "Copy", "Paste" the playground menu uses a different order "Copy", "Cut" "Paste". => CONFUSING again
I would suggest to use the well known order "Cut","Copy","Paste".
Thanks for noticing. This will be fixed.
3. When one uses "Inspect it" from the context menu it means - to run the code - and the resulting object is then "inspectable" in a new window
On the other side "Do it and go" from the context menu means - to run the code - and the resulting object is then "inspectable" in a new pane (but same window)
The intention of both menu items and also the result is the same, but the naming is different ("go" vs. "inspect"). But the only notable difference is that in one case the inspectable object is opening right to the existing pane in the other case a new window is opened.
=> CONFUSING and inconsistent
This is harder to solve. Possible solutions are:
3a. We keep the "inspect" concept and name the menu items "Do and Inspect it" and "Inspect in new window"
3b. We keep "Do it" as before to run the code, also "Inspect it" which opens the new pane to the left in the same window. If someone wants to open a new inspector window he should keep SHIFT key pressed while running "Inspect it". This is a concept known from web browsers and other tools today, clicking on a link while pressing SHIFT opens a new window.
Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g. I proposed "gInspect it", but that is perhaps less fortunate :). You say that the intention is the same, but is is not. Having it opened to the right has the intention of keeping track of the path of inspection (we call it the inspection session). That is different from spawning an unrelated window. What other proposal would you have?
4. The icons in the context menu of Playground are not the same as the ones in the Pharo browsers.
=> CONFUSING and inconsistent
They are just black and if one switches to the Pharo dark theme they stay black and therefore looking ugly and make nearly no sense on the dark grey menu background.
For now we should use the known icons that we already have. Maybe currently they are hardcoded and may conflict with Moose vs. Pharo icons - but this could be solved with the Icon Theming.
This is a known issue and we will look at it soon.
(In the long term I would like to see scalable icons in Pharo menues (instead of bitmaps) similar to "Fontawesome" in web browsers (two colors) or SVG based ones (more colors) as currently the icon does not scale when changing the menue font size).
Me too!
Sorry if it sound like a rant - but the intention of this mail is that we discuss (and hopefully fix) in order to improve.
It's not a rant at all.
Maybe it is written too early after the initial integration, but I think the mentioned points should be easy to address. Unfortunately I'm additionally confused with the changed contribution process that has exceptions for specific packages like GT to fix it myself with the usualy bugs/slice cycle.
At the moment, GT is an external project and the contributions should happen directly in its repository. Cheers, Doru
Thanks T.
-- www.tudorgirba.com "Every thing has its own flow"
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is that the Playground is such a distinct departure from the Workspace that it deserves a different name.
I agree, it should not be named Workspace but on the other hand I feel also that "Playground" does not quite represent the raw power of the tool. But it definitely should not be named Workspace.
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground. And the playground for what it is meant to do. These two things are *not* for the same use case. âPhil
Hi, I do not quite understand this point of view. If you do not use "Go", there is no right side. What do you mean by CLI? Cheers, Doru On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote:
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com "Every thing has its own flow"
I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code. Suggestions: on "Esc" close the popup and unselect the current selection on "Enter" insert the printIt-result. 2014-10-16 21:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I do not quite understand this point of view. If you do not use "Go", there is no right side.
What do you mean by CLI?
Cheers, Doru
On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote:
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com
"Every thing has its own flow"
Hi Nicolai, On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess <nicolaihess@web.de> wrote:
I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection
Good point.
on "Enter" insert the printIt-result.
Indeed, this is something I thought of, too. However, I am not convinced that the frequency of needing to insert the result of "print it" warrants a shortcut that can be so easily use (i.e., Enter can be used also for adding a line). Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v. Cheers, Doru
2014-10-16 21:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I do not quite understand this point of view. If you do not use "Go", there is no right side.
What do you mean by CLI?
Cheers, Doru
On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote:
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Oct 2014, at 22:34, Tudor Girba <tudor@tudorgirba.com> wrote:
On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess <nicolaihess@web.de> wrote: I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection
Good point.
+1
on "Enter" insert the printIt-result.
Indeed, this is something I thought of, too. However, I am not convinced that the frequency of needing to insert the result of "print it" warrants a shortcut that can be so easily use (i.e., Enter can be used also for adding a line). Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v.
+1 I also don't think 'Print It' is not that common, and if you use it you want the output to be in a comment anyway so the syntax highlighting doesn't make everything red. I also wanted to add that the whole idea of GT-Tools is to do a lot and even more powerful things based on a few simple concepts. We are currently making lots of small usability changes, which is all good, but we have to guard the simplicity.
Sven Van Caekenberghe wrote:
On 16 Oct 2014, at 22:34, Tudor Girba <tudor@tudorgirba.com> wrote:
On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess <nicolaihess@web.de> wrote: I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection
Good point.
+1
on "Enter" insert the printIt-result.
Indeed, this is something I thought of, too. However, I am not convinced that the frequency of needing to insert the result of "print it" warrants a shortcut
I often have a few lines of snippets listed in a Workspace that I want to compare the results, or copy/paste the lot to some documentation. I was thinking of asking for a <pin> icon/button, but inserting as text is a better idea.
that can be so easily use (i.e., Enter can be used also for adding a line). Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v.
I would go for <space> rather than <enter>, since intuitively that keeps you on the same line.
I also don't think 'Print It' is not that common, and if you use it you want the output to be in a comment anyway so the syntax highlighting doesn't make everything red.
When the result is inserted, surrounding it by comment quotes is a good idea. cheers -ben
I also wanted to add that the whole idea of GT-Tools is to do a lot and even more powerful things based on a few simple concepts.
We are currently making lots of small usability changes, which is all good, but we have to guard the simplicity.
On 17 Oct 2014, at 02:40, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
On 16 Oct 2014, at 22:34, Tudor Girba <tudor@tudorgirba.com> wrote:
On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess <nicolaihess@web.de> wrote: I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection
Good point. +1 on "Enter" insert the printIt-result.
Indeed, this is something I thought of, too. However, I am not convinced that the frequency of needing to insert the result of "print it" warrants a shortcut
I often have a few lines of snippets listed in a Workspace that I want to compare the results, or copy/paste the lot to some documentation. I was thinking of asking for a <pin> icon/button, but inserting as text is a better idea.
that can be so easily use (i.e., Enter can be used also for adding a line). Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v.
I would go for <space> rather than <enter>, since intuitively that keeps you on the same line.
but also enter means âacceptâ in everybodyâs brain (and other tools prefer that over space). anyway, +1 to that⦠is something that I really miss. Esteban
I also don't think 'Print It' is not that common, and if you use it you want the output to be in a comment anyway so the syntax highlighting doesn't make everything red.
When the result is inserted, surrounding it by comment quotes is a good idea.
cheers -ben
I also wanted to add that the whole idea of GT-Tools is to do a lot and even more powerful things based on a few simple concepts. We are currently making lots of small usability changes, which is all good, but we have to guard the simplicity.
Indeed, the print it can surely be improved. Since I am using GTInspector, I often open a transcript and do "myObject logCrâ I usually do this to have a string representation, useful to insert in source code. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 16, 2014, at 5:23 PM, Nicolai Hess <nicolaihess@web.de> wrote:
I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection on "Enter" insert the printIt-result.
2014-10-16 21:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
I do not quite understand this point of view. If you do not use "Go", there is no right side.
What do you mean by CLI?
Cheers, Doru
On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote: I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com
"Every thing has its own flow"
I do not quite understand. Could you elaborate such a case? (I am not being thick headed, I just did not encounter this case, so I would like to know more about it) Doru On Thu, Oct 16, 2014 at 10:34 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Indeed, the print it can surely be improved. Since I am using GTInspector, I often open a transcript and do "myObject logCrâ I usually do this to have a string representation, useful to insert in source code.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 16, 2014, at 5:23 PM, Nicolai Hess <nicolaihess@web.de> wrote:
I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection on "Enter" insert the printIt-result.
2014-10-16 21:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I do not quite understand this point of view. If you do not use "Go", there is no right side.
What do you mean by CLI?
Cheers, Doru
On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote:
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
I find that interesting that you do not have seen this. I made a small video. Here is a session: https://dl.dropboxusercontent.com/u/31543901/TMP/PrintingWithGTInspector.mov What the session does not show, is that I open the view usually to make sure the result is indeed correct. Let me know what you think. This is something very frequent in my programming style. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 16, 2014, at 5:37 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
I do not quite understand. Could you elaborate such a case? (I am not being thick headed, I just did not encounter this case, so I would like to know more about it)
Doru
On Thu, Oct 16, 2014 at 10:34 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Indeed, the print it can surely be improved. Since I am using GTInspector, I often open a transcript and do "myObject logCrâ I usually do this to have a string representation, useful to insert in source code.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 16, 2014, at 5:23 PM, Nicolai Hess <nicolaihess@web.de> wrote:
I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". On "Esc", the popup closes , but the code is still selected. Most of the time I want to go on typing, but first I have to unselect the code.
Suggestions: on "Esc" close the popup and unselect the current selection on "Enter" insert the printIt-result.
2014-10-16 21:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
I do not quite understand this point of view. If you do not use "Go", there is no right side.
What do you mean by CLI?
Cheers, Doru
On Thu, Oct 16, 2014 at 9:01 PM, phil@highoctane.be <phil@highoctane.be> wrote: I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
âPhil
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Tudor Girba-2 wrote
I do not quite understand. Could you elaborate such a case?
When writing a conditional that is true in the current image state, e.g. Smalltalk imageFile base = 'foo' ifTrue: [] it's quite convenient to write: Smalltalk imageFile base then PrintIt, left arrow and type ' =' ----- Cheers, Sean -- View this message in context: http://forum.world.st/Playground-and-its-current-usability-in-Pharo4-0-Lates... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 16 Oct 2014, at 21:01, phil@highoctane.be wrote:
I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground.
And the playground for what it is meant to do.
These two things are *not* for the same use case.
yes, they should. If they are not then we have an error somewhere. Could you elaborate a bit on why they are not fulfilling same usecase for you? cheers, Esteban ps: In the future (not in pharo4, certainly), old workspace and inspectors will be removed from environment, so we need to make sure the new ones can do the job correctly.
âPhil
Tudor wrote:
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is >that the Playground is such a distinct departure from the Workspace that it deserves a different name.
I do not think it is a departure from the Workspace concept. Therefore I would keep "Workspace" for the menu item name and the window name. It would be enough if the initial tab is called "Playground" because one can play in the code pane (or do serious stuff). This way we would keep up with a known concept (also from other IDE's), it meets what people would expect and no books would have to be rewritten ;) BTW: Squeak had a goodie with something similar back in the days (cant remember the name). It was neat as one could assemble different objects and different object representations in one navigateable window.
I would suggest to use the well known order "Cut","Copy","Paste". Thanks for noticing. This will be fixed.
Thanks! Â Â
Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g.
Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss the discussion in the list or was it offlist?
...icons... This is a known issue and we will look at it soon.  Sounds good.  At the moment, GT is an external project and the contributions should happen directly in its repository.
Then please add me to the repo. Still the process is unclear - will I still provide a slice with issue number or will I change the config. It is not very lucky that this process was started (without discussion/announcement/description first and only for specific packages). Thx T.
On Thu, Oct 16, 2014 at 5:58 PM, Torsten Bergmann <astares@gmx.de> wrote:
Tudor wrote:
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is >that the Playground is such a distinct departure from the Workspace that it deserves a different name.
I do not think it is a departure from the Workspace concept.
Therefore I would keep "Workspace" for the menu item name and the window name. It would be enough if the initial tab is called "Playground" because one can play in the code pane (or do serious stuff).
This way we would keep up with a known concept (also from other IDE's), it meets what people would expect and no books would have to be rewritten ;)
BTW: Squeak had a goodie with something similar back in the days (cant remember the name). It was neat as one could assemble different objects and different object representations in one navigateable window.
I would suggest to use the well known order "Cut","Copy","Paste". Thanks for noticing. This will be fixed.
Thanks!
Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g.
Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss the discussion in the list or was it offlist?
...icons... This is a known issue and we will look at it soon.
Sounds good.
At the moment, GT is an external project and the contributions should happen directly in its repository.
Then please add me to the repo. Still the process is unclear - will I still provide a slice with issue number or will I change the config.
I've added you to the moose team. If you want to fix something just commit it to the moose repo. If there is an issue, after you commit mark the issue as fix review needed and add a comment that there'a fix in the project's repo. Once or twice a week I make a new version of GTools with all the new packages that get's integrated into Pharo Cheers, Andrei
It is not very lucky that this process was started (without discussion/announcement/description first and only for specific packages).
Thx T.
Hi, On Thu, Oct 16, 2014 at 10:58 PM, Torsten Bergmann <astares@gmx.de> wrote:
Tudor wrote:
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is >that the Playground is such a distinct departure from the Workspace that it deserves a different name.
I do not think it is a departure from the Workspace concept.
Therefore I would keep "Workspace" for the menu item name and the window name. It would be enough if the initial tab is called "Playground" because one can play in the code pane (or do serious stuff).
I disagree. Workspace has a very specific meaning in the way it is being used, and this is now obsolete.
This way we would keep up with a known concept (also from other IDE's)
You mean like the Playground in Swift (btw, we named it playground before Swift appeared)? :) The philosophy of the name is to support the idea that in Pharo we play with objects, and play with do in a Playground. But, we can still find another name if wanted, just not workspace. For example, it can be something about starting, or entering a space. I would also prefer having something that ends with an "er" or "or" like the Inspector or Debugger. it meets what people would expect and
no books would have to be rewritten ;)
I disagree again. Books will actually have to rewritten :) BTW: Squeak had a goodie with something similar back in the days (cant
remember the name). It was neat as one could assemble different objects and different object representations in one navigateable window.
That is great to hear. Was it the work of Marcel Taeumel on Vivide ( http://www.taeumel.eu), or something else? Only, the Playground is not just windows stacked to one another, it's a whole session that can be reasoned about.
I would suggest to use the well known order "Cut","Copy","Paste". Thanks for noticing. This will be fixed.
Thanks!
Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g.
Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss the discussion in the list or was it offlist?
You missed the discussion. It was on this list, but we can start it again. Could you open another thread?
...icons... This is a known issue and we will look at it soon.
Sounds good.
At the moment, GT is an external project and the contributions should happen directly in its repository.
Then please add me to the repo. Still the process is unclear - will I still provide a slice with issue number or will I change the config.
At the moment, we are taking an optimistic approach to committing, so you can commit directly in the GT repository. You can also commit either in your own repository and send us a ping. Because of the optimistic approach, it is better to have a discussion beforehand, either through an issue or via the mailing list. When we are all happy (it can be that a change is reverted), we create a new stable version that afterwards has to be integrated into Pharo. I believe that after a while, we should eliminate the last step and have Pharo integrate the latest stable, but we need a transition period. It is not very lucky that this process was started (without
discussion/announcement/description first and only for specific packages).
Again, you missed this discussion. Btw, this is how Zinc was handled since quite a long time, and we want to move Pharo to be handled via configurations in separate repositories from now on. This is a way to scale the effort by not making the central team responsible for everything. Cheers, Doru
Thx T.
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Oct 2014, at 22:58, Torsten Bergmann <astares@gmx.de> wrote:
Tudor wrote:
Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is >that the Playground is such a distinct departure from the Workspace that it deserves a different name.
I do not think it is a departure from the Workspace concept.
Therefore I would keep "Workspace" for the menu item name and the window name. It would be enough if the initial tab is called "Playground" because one can play in the code pane (or do serious stuff).
This way we would keep up with a known concept (also from other IDE's), it meets what people would expect and no books would have to be rewritten ;)
BTW: Squeak had a goodie with something similar back in the days (cant remember the name). It was neat as one could assemble different objects and different object representations in one navigateable window.
I would suggest to use the well known order "Cut","Copy","Paste". Thanks for noticing. This will be fixed.
Thanks!
Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be the name of the action that is mapped on Cmd+g.
Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss the discussion in the list or was it offlist?
basically, it was decided by me (and the course of the actions⦠I did not forced anyone :P). My reasons remain but I have to say: 1) Survey reflected a clear position towards what now is called 3b 2) We are still making tests⦠nothing is written in stone and we are looking for better ways to do things⦠so that can change again (and again, and again, and like that until we are happy)
...icons... This is a known issue and we will look at it soon.
Sounds good.
At the moment, GT is an external project and the contributions should happen directly in its repository.
Then please add me to the repo. Still the process is unclear - will I still provide a slice with issue number or will I change the config.
It is not very lucky that this process was started (without discussion/announcement/description first and only for specific packages).
Thx T.
participants (11)
-
Alexandre Bergel -
Andrei Chis -
Ben Coman -
Esteban Lorenzano -
kilon alios -
Nicolai Hess -
phil＠highoctane.be -
Sean P. DeNigris -
Sven Van Caekenberghe -
Torsten Bergmann -
Tudor Girba