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

Re: [Pharo-dev] Google Code Shutdown

by Alexandre Bergel

Github is indeed appealing. Cheers, Alexandre > On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> Would you like to help us move the moose-technology project? > > Sure. What do you have in mind? It seems exporting to GitHub is the easiest > option. There are a few limitations, but I've had good experiences... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 3, 2015

Re: [Pharo-dev] Google Code Shutdown

by Sean P. DeNigris

Tudor Girba-2 wrote > Would you like to help us move the moose-technology project? Sure. What do you have in mind? It seems exporting to GitHub is the easiest option. There are a few limitations, but I've had good experiences... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Stephan Eggermont

On 01/08/15 13:25, Franck Warlouzet wrote: > Hello, > > Yes it looks a little bit 'lite' but we did not want to have 2 buttons > with the same look but two different kinds of actions. Hierarchy button > changes the window itself and variable and scoped open a new menu or > window. > > I agree about the class side button. Every button in the Nautilus browser has lots of improvement potential. It should be visually clear where a button applies to. Scoped applies to the package pane, Variables to the class pane, Hierarchy/Flat to the class pane, Class side to the methods and methods category pane and comments to the text pane. The location of the buttons could reflect that. It should be visually clear if a button represents a direct action, an indirect action, shows a menu, represents a state change action or the current state or opens a menu The buttons should have hover texts explaining what the button does and when it is (and not) applicable. A button should react to left-click only, not to right-click (or with a menu to right click). And then there are also some Rubric widgets in the text pane that behave somewhat like buttons. And now for something completely different: Why are the variables shown in reversed order? I rarely look for users of DependentFields Stephan

Aug. 2, 2015

Re: [Pharo-dev] [ann] jdt2famix - an open-source java importer project

by Tudor Girba

Hi (again), The project below is made possible by JNIPort. Thanks, Joachim! Cheers, Doru On Sun, Aug 2, 2015 at 11:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I would like to announce the jdt2famix project. This aims to be an > open-source solution for importing Java projects into Moose: > http://www.smalltalkhub.com/#!/~Moose/Jdt2Famix > > The project is based on: > - JDT for raw parsing. This is implemented in Java. > - JNIPort for delegating to Pharo the Java methods that visit the Java AST. > > Installation details can be found on the main project page. > > The current importing logic is rudimentary, but the first goal was to > setup the whole ping-pong between Pharo and Java. This one works, and I am > quite happy about that. You can take a look at the JdtImporterTest. > > CAVEATS: > - Due to a problem in JNIPort, currently, this project only works in Moose > 5.0. > - Also, for now it works out of the box only for Mac OS X. > - And, on top of that, it requires Java 1.6 for now (until we will get the > Spur VM on 64 bits). > > There are still quite some challenges left, but once we get this going, we > would also be able to use deep AST analysis live, and to do incremental > model update when something changes on disk. Furthermore, if it scales, > this would not be based on an intermediary MSE file anymore. > > I would like to ask for help in several directions: > 1. Implement the full model import. This would require diving into JDT and > implementing the corresponding mapping logic. I spent a few days on this. > It is hairy, but it is not that impossible (only it has a ton of edge > cases). This should be test driven, in that, for each case, we need to have > a corresponding sample. > 2. Fix JNIPort to work in Pharo 5. > 3. Get the whole thing to work out of the box for Linux and Windows. > 4. Check scalability. > > Please let me know your opinions, and let me know if you would like to > participate. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 2, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Esteban Lorenzano

> On 01 Aug 2015, at 22:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > On Sat, Aug 1, 2015 at 10:10 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > Le 1/8/15 13:54, Esteban Lorenzano a Ã©crit : >> >>> On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet(a)hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote: >>> >>> Hello, >>> >>> Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. >> >> but they are buttons, then they should look like one. >> alsoâ¦ âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)â¦ it increases confusion instead solving a problem. >> we need a better general approach for those actions, maybe a toolbar or something like thatâ¦ but as it is now it does not work. > > Yes we know. > Now there is a difference between a button popping something and one just acting on the default browser. > > But does there need to be a distinction? > > If I DON'T know what the button does, then distinction, unless it is well known, will not help me, because I will not know what the distinction means. > > And if I DO know what it does, then I don't care about the distinction anymore. > > So if you want to visualize it, then it must be something that is well known. > For example "Print ..." (dotdotdot) means "Clicking on this will not print immediately, but will open a new window with some more stuff.", > or the V triangle down signifies that it will open a dropdown menu. > > And even with these minor UI/UX details, most people don't even realize it's there and will just memorize and internalize the process, +1000 is complete non-sense to change form of buttons just because they trigger a different action. basically, all rules of UI design are against it. Every year we have same discussion, and every year I point to the same readings: - âdonât make me thinkâ. https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think <https://en.wikipedia.org/wiki/Don't_Make_Me_Think> - the mac UI design guidelines. https://developer.apple.com/library/mac/documentation/UserExperience/Concep… <https://developer.apple.com/library/mac/documentation/UserExperience/Concep…> there are many papers, research, etc. around this but wellâ¦ here is a *very* simplified summary of principles: http://web.cs.wpi.edu/~matt/courses/cs563/talks/smartin/int_design.html <http://web.cs.wpi.edu/~matt/courses/cs563/talks/smartin/int_design.html> And even more simplified: Coherence (same metaphor), organisation (same layout), uniqueness (same elements) So, a button is a button. If we present them as links, then ALL buttons should be a link. If they are âold-styleâ buttons, then ALL buttons should be old style. Esteban > > Peter

Aug. 2, 2015

Re: [Pharo-dev] Google Code Shutdown

by Tudor Girba

Hi Sean, Would you like to help us move the moose-technology project? Cheers, Doru On Sun, Aug 2, 2015 at 5:19 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote > > In case anyone hasn't heard, Google Code will shut down entirely on > > January 25, 2016. > > UPDATE: Impending Deadline: "Google Code will be turning read-only on > August > 25th" > > Already Moved: > magritte-metamodel > phratch > seaside > metacello > > Unknown: > moose-technology > marsonpharo > nativeboost > squeaksource3 > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Google-Code-Shutdown-tp4814760p4840717.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 2, 2015

Re: [Pharo-dev] Google Code Shutdown

by Sean P. DeNigris

Sean P. DeNigris wrote > In case anyone hasn't heard, Google Code will shut down entirely on > January 25, 2016. UPDATE: Impending Deadline: "Google Code will be turning read-only on August 25th" Already Moved: magritte-metamodel phratch seaside metacello Unknown: moose-technology marsonpharo nativeboost squeaksource3 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-Code-Shutdown-tp4814760p4840717.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Alexandre Bergel

Why not making the label text change color when the mouse is above? This cheap to do Alexandre > Le 1 aoÃ»t 2015 Ã 08:56, stepharo <stepharo(a)free.fr> a Ã©crit : > > Yes I think that we should do something to make sure that we understand that this is a button. > > Stef > > >

Aug. 2, 2015

Re: [Pharo-dev] cleanup rubric

by Esteban Lorenzano

> On 02 Aug 2015, at 10:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>>: > > > > Hello all, > > Yes we have both PluggableTextMorph and Rubric so it is a mess. > > Yes Rubric was a fork, so a lot of code is duplicated. > > I would say just wait that all PluggableTextMorph uses are removed > > then we will be able to clean-up things. > > Now, remember that I was not so excited by Rubric as the default editor. > > Rubric is the past, It should be removed asap with all the crap that it duplicates. > > I would not invest to much time in cleaning and commenting it. > > Instead, clean, document and implement tests for TxText. > > Really? We move from pluggabletextmorph to rubric, just to move again to txtext? > TxText should be the future because of many reasonsâ¦ but is unfinished and far from it, so no idea when we will be actually ready. in the mean time Rubric is good and finished :) Esteban > > > > Cheers > > Alain > > > > > > > On 01 Aug 2015, at 11:22, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > > > Yes the situation with rubric is a real mess :( > > > Ideally I would like to throw away text and rub altogether. > > > Now I would like to understand what is a good path that minimise > > > duplication. > > > > > > In addition I do not understand why certain class extensions are not the same in both packages. > > > So I will try to get some time to read code and come with a list of actions. > > > If you have some ideas I'm interested. > > > > > > Stef > > > > > >>> Maybe I am wrong, but it looks like there are many > > >>> classes and code in rubric that are the same as in the old Text classes. > > >> > > >> Yes never said that Rubric is the future. He just improved a bit > > >> > > >>> Rub is used in GT and now in the Core image. Shouldn't we clean this up > > >>> before it used everywhere? > > >>> > > >>> Some examples: > > >>> > > >>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink) > > >>> > > >>> MorphAnnouncement subclass: #RubMorphAnnouncement > > >>> RubMorphAnnouncment adds nothing > > >>> > > >>> FindReplaceService <-> RubFindReplaceService > > >>> They look very similar, I don't understand why so much code is > > >>> just the same in both, why not extract that into a base class? > > >>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow > > >>> and some many too) > > >>> > > >>> RubEditingState / EditingState. > > >>> > > >>> What this makes it even worse, Rubs class comment doesn't indicate how > > >>> they differ from the old other one. > > >> True. > > >>> It is really difficult to understand, > > >>> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework. > > >>> - wich classes are used but could be replaced with the existing one (TextLink for example) > > >>> - which classes had to be changed, and therefore only the Rub-classes can work with rubric. > > >>> - which classes are similiar named like the old Text classes and share some code but may work > > >>> totally different. > > >>> > > >>> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used > > >>> anywhere, it looks like RubTextEditor is just > > >>> - a copy from TextEditor, > > >>> - changed where it was needed > > >>> - unchanged otherwise > > >> Yes. I think that alain did it like that. He just wanted to offer some behavior for the Moosers. > > >>> Rubric really adds some great new things and if you look at where it is used, it > > >>> is really a great step forward, but the code is in a bad state. > > >>> This needs to be cleaned up. > > >> Definitively. > > >> Nicolai > > >> do you have a list of actions? > > >> because I would like to do some of them. > > >> We could remove the duplicate. This is what we started to do with PluggableTextMorph. > > >> > > >> > > > > > > > >

Aug. 2, 2015

Re: [Pharo-dev] cleanup rubric

by Nicolai Hess

Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <alain.plantec(a)yahoo.com>: > > Hello all, > Yes we have both PluggableTextMorph and Rubric so it is a mess. > Yes Rubric was a fork, so a lot of code is duplicated. > I would say just wait that all PluggableTextMorph uses are removed > then we will be able to clean-up things. > Now, remember that I was not so excited by Rubric as the default editor. > Rubric is the past, It should be removed asap with all the crap that it duplicates. > I would not invest to much time in cleaning and commenting it. > Instead, clean, document and implement tests for TxText. Really? We move from pluggabletextmorph to rubric, just to move again to txtext? > > Cheers > Alain > > > > On 01 Aug 2015, at 11:22, stepharo <stepharo(a)free.fr> wrote: > > > > Yes the situation with rubric is a real mess :( > > Ideally I would like to throw away text and rub altogether. > > Now I would like to understand what is a good path that minimise > > duplication. > > > > In addition I do not understand why certain class extensions are not the same in both packages. > > So I will try to get some time to read code and come with a list of actions. > > If you have some ideas I'm interested. > > > > Stef > > > >>> Maybe I am wrong, but it looks like there are many > >>> classes and code in rubric that are the same as in the old Text classes. > >> > >> Yes never said that Rubric is the future. He just improved a bit > >> > >>> Rub is used in GT and now in the Core image. Shouldn't we clean this up > >>> before it used everywhere? > >>> > >>> Some examples: > >>> > >>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink) > >>> > >>> MorphAnnouncement subclass: #RubMorphAnnouncement > >>> RubMorphAnnouncment adds nothing > >>> > >>> FindReplaceService <-> RubFindReplaceService > >>> They look very similar, I don't understand why so much code is > >>> just the same in both, why not extract that into a base class? > >>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow > >>> and some many too) > >>> > >>> RubEditingState / EditingState. > >>> > >>> What this makes it even worse, Rubs class comment doesn't indicate how > >>> they differ from the old other one. > >> True. > >>> It is really difficult to understand, > >>> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework. > >>> - wich classes are used but could be replaced with the existing one (TextLink for example) > >>> - which classes had to be changed, and therefore only the Rub-classes can work with rubric. > >>> - which classes are similiar named like the old Text classes and share some code but may work > >>> totally different. > >>> > >>> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used > >>> anywhere, it looks like RubTextEditor is just > >>> - a copy from TextEditor, > >>> - changed where it was needed > >>> - unchanged otherwise > >> Yes. I think that alain did it like that. He just wanted to offer some behavior for the Moosers. > >>> Rubric really adds some great new things and if you look at where it is used, it > >>> is really a great step forward, but the code is in a bad state. > >>> This needs to be cleaned up. > >> Definitively. > >> Nicolai > >> do you have a list of actions? > >> because I would like to do some of them. > >> We could remove the duplicate. This is what we started to do with PluggableTextMorph. > >> > >> > > > > >

Aug. 2, 2015