- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Nautilus Tree

by kilon alios

ok I found this after some google search -> http://rmod.lille.inria.fr/web/pier?_s=HmL1nFoP1weCzRt7 . Is there any more recent documentation on Nautilus plugin system or any other way of extending Nautilus ? On Mon, Dec 2, 2013 at 11:05 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > "It's done for me (with the added fact that you want to return the search > results inside the system browser itself: done for me too). For Nautilus, > there is a need to reactivate the Finder plugin." > > that's great to hear, this makes things much easier for me. How to > reactivate that plugin ? Also where I can find documentation for the > Nautilus plugin system ? I have no intention of reinventing the wheel, if I > can just extend Nautilus that would be great. Having this option means I > could even start Cyclops now, cause it will take me much less time than I > expected. > > "Takes ages to tag correctly a system as large as Pharo nowadays. > > Such a graph can also makes things very complex at times. You may want to > look into dynamic tagging... which brings you to scoped browsing, more or > less. > " > > My plan was to offer tagging for some classes I heavily use but obviously > not all. I wanted to allow user to create their own tags even custom ones > and sync automatically with other users against a common online tag > repository. > > "Up to you :) > > Me, I have a fairly good spatial memory, so a tree helps me because I can > remember where things are (and the tree also shorten long package names > ;))." > > It was not my intention to offer ONLY a tag system, hierarchy trees are > useful too. I see the tag system as another alternative way of viewing > classes and methods not as a complete replacement to hierarchy trees.Also > the tree hides part of the name but force you to make long package names to > use the tree anyway. Am I wrong ? > > " Beware: there is no common logic in that (you're a specific case, I'd > be very unhappy with your GUI as far as I can see, and the reverse is also > true). " > > Common logic means exactly what is implied, logic which some people agree > on. Obviously nothing is absolute and people have different workflow which > I respect and love to hear about them ;) I definitely would not want to > force people doing things a single way. Anything can useful. > > "Do it, do it! As I experienced myself, it's fairly easy to rebuilt a > complete system browser..." > > Is it or are you being sarcastic ? It was never my intention to rebuilt a > complete system browser, just reskin and extend the existing one. I find > the system browser already extremely powerful and fun to use , I just > wanted to add my own touches to it. This is why I was considering Glamour . > > > On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > >> >> >> Le 29/11/2013 18:16, kilon alios a Ã©crit : >> >> Currently I am working on Hyperion, a vector editor for Athens. Then I >>> will work on Prometheas, on board documentation tool again with Athens. >>> >>> My third tool, if ever reach that far is Cyclops which will target the >>> system browser. Now I am no fan of hierarchy trees. I find them hard to >>> navigate and messy when hierarchy gets too complex. I see two solution >>> on this one >>> >>> a) Sophisticated search facility, we have that already with the finder >>> tool . I feel its time for the finder tool to go and be one with the >>> system browser. >>> >> >> It's done for me (with the added fact that you want to return the search >> results inside the system browser itself: done for me too). For Nautilus, >> there is a need to reactivate the Finder plugin. >> >> >> b) Tag based browsing. That means attach tags to your classes and >>> methods , make it easy this way to make things belong to groups and most >>> importantly one thing could belong to more than one group. This also >>> means bye bye packages, and instead replaced with infinite level groups, >>> a group can be inside another group which can be inside another group >>> etc. Of course those groups wont "exist" only their tags will "exist". >>> >> >> Takes ages to tag correctly a system as large as Pharo nowadays. >> >> Such a graph can also makes things very complex at times. You may want to >> look into dynamic tagging... which brings you to scoped browsing, more or >> less. >> >> >> I am also smiling to the Glamour philosophy of having a browser tool >>> that can have multiple ways of viewing your classes. Bottom line is that >>> I will be using existing ideas and I hope also code to push things just >>> tiny bit further. >>> >> >> Do it, do it! As I experienced myself, it's fairly easy to rebuilt a >> complete system browser... >> >> >> So for me at least smart browsing plus tags plus good search facility >>> can easily replace ugly hierarchy trees and packages with really long >>> names. >>> >> >> Up to you :) >> >> Me, I have a fairly good spatial memory, so a tree helps me because I can >> remember where things are (and the tree also shorten long package names ;)). >> >> >> Just using common logic can take you a long way into improving the >>> tools, the hard part is actually coding all this because it takes time >>> and effort. >>> >> >> Beware: there is no common logic in that (you're a specific case, I'd be >> very unhappy with your GUI as far as I can see, and the reverse is also >> true). >> >> >>> On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <sean(a)clipperadams.com >>> <mailto:sean@clipperadams.com>> wrote: >>> >>> kilon alios wrote >>> > I dont see much room for thought, this looks to me like ideal >>> behavior. >>> >>> I agree in theory, but it seems that the tree is primarily about >>> chunking >>> information into manageable pieces. >>> >>> A primary difficulty here is that packages are often divided for >>> reasons >>> that have nothing to do with the domain model, e.g. the ubiquitous >>> MyPackage-Platform, which is an artifact of Metacello that is not >>> all that >>> relevant to a user wanting to understand the system. >>> >>> >From the naive user perspective, if I'm exploring from the top >>> level of the >>> system, I want to see things like: >>> - CodeImport >>> - Collections >>> - Compiler >>> >>> >From this perspective, the 14 entries for Collections, multiplied >>> by a few >>> dozen top-level categories make the list unwieldy and only >>> marginally less >>> daunting than the flattened list we used to have (see >>> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_ >>> Plus_or_Minus_Two >>> ): >>> <http://forum.world.st/file/n4726287/Picture_1.png> >>> >>> >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >>> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >

Dec. 2, 2013

Re: [Pharo-dev] Nautilus Tree

by kilon alios

"It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin." that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. "Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. " My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. "Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;))." It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? " Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). " Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. "Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser..." Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > > > Le 29/11/2013 18:16, kilon alios a Ã©crit : > > Currently I am working on Hyperion, a vector editor for Athens. Then I >> will work on Prometheas, on board documentation tool again with Athens. >> >> My third tool, if ever reach that far is Cyclops which will target the >> system browser. Now I am no fan of hierarchy trees. I find them hard to >> navigate and messy when hierarchy gets too complex. I see two solution >> on this one >> >> a) Sophisticated search facility, we have that already with the finder >> tool . I feel its time for the finder tool to go and be one with the >> system browser. >> > > It's done for me (with the added fact that you want to return the search > results inside the system browser itself: done for me too). For Nautilus, > there is a need to reactivate the Finder plugin. > > > b) Tag based browsing. That means attach tags to your classes and >> methods , make it easy this way to make things belong to groups and most >> importantly one thing could belong to more than one group. This also >> means bye bye packages, and instead replaced with infinite level groups, >> a group can be inside another group which can be inside another group >> etc. Of course those groups wont "exist" only their tags will "exist". >> > > Takes ages to tag correctly a system as large as Pharo nowadays. > > Such a graph can also makes things very complex at times. You may want to > look into dynamic tagging... which brings you to scoped browsing, more or > less. > > > I am also smiling to the Glamour philosophy of having a browser tool >> that can have multiple ways of viewing your classes. Bottom line is that >> I will be using existing ideas and I hope also code to push things just >> tiny bit further. >> > > Do it, do it! As I experienced myself, it's fairly easy to rebuilt a > complete system browser... > > > So for me at least smart browsing plus tags plus good search facility >> can easily replace ugly hierarchy trees and packages with really long >> names. >> > > Up to you :) > > Me, I have a fairly good spatial memory, so a tree helps me because I can > remember where things are (and the tree also shorten long package names ;)). > > > Just using common logic can take you a long way into improving the >> tools, the hard part is actually coding all this because it takes time >> and effort. >> > > Beware: there is no common logic in that (you're a specific case, I'd be > very unhappy with your GUI as far as I can see, and the reverse is also > true). > > >> On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <sean(a)clipperadams.com >> <mailto:sean@clipperadams.com>> wrote: >> >> kilon alios wrote >> > I dont see much room for thought, this looks to me like ideal >> behavior. >> >> I agree in theory, but it seems that the tree is primarily about >> chunking >> information into manageable pieces. >> >> A primary difficulty here is that packages are often divided for >> reasons >> that have nothing to do with the domain model, e.g. the ubiquitous >> MyPackage-Platform, which is an artifact of Metacello that is not >> all that >> relevant to a user wanting to understand the system. >> >> >From the naive user perspective, if I'm exploring from the top >> level of the >> system, I want to see things like: >> - CodeImport >> - Collections >> - Compiler >> >> >From this perspective, the 14 entries for Collections, multiplied >> by a few >> dozen top-level categories make the list unwieldy and only >> marginally less >> daunting than the flattened list we used to have (see >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_ >> Plus_or_Minus_Two >> ): >> <http://forum.world.st/file/n4726287/Picture_1.png> >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

Dec. 2, 2013

Re: [Pharo-dev] Nautilus Tree

by Goubier Thierry

Le 29/11/2013 18:16, kilon alios a Ã©crit : > Currently I am working on Hyperion, a vector editor for Athens. Then I > will work on Prometheas, on board documentation tool again with Athens. > > My third tool, if ever reach that far is Cyclops which will target the > system browser. Now I am no fan of hierarchy trees. I find them hard to > navigate and messy when hierarchy gets too complex. I see two solution > on this one > > a) Sophisticated search facility, we have that already with the finder > tool . I feel its time for the finder tool to go and be one with the > system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. > b) Tag based browsing. That means attach tags to your classes and > methods , make it easy this way to make things belong to groups and most > importantly one thing could belong to more than one group. This also > means bye bye packages, and instead replaced with infinite level groups, > a group can be inside another group which can be inside another group > etc. Of course those groups wont "exist" only their tags will "exist". Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. > I am also smiling to the Glamour philosophy of having a browser tool > that can have multiple ways of viewing your classes. Bottom line is that > I will be using existing ideas and I hope also code to push things just > tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... > So for me at least smart browsing plus tags plus good search facility > can easily replace ugly hierarchy trees and packages with really long > names. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). > Just using common logic can take you a long way into improving the > tools, the hard part is actually coding all this because it takes time > and effort. Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). > > On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > kilon alios wrote > > I dont see much room for thought, this looks to me like ideal > behavior. > > I agree in theory, but it seems that the tree is primarily about > chunking > information into manageable pieces. > > A primary difficulty here is that packages are often divided for reasons > that have nothing to do with the domain model, e.g. the ubiquitous > MyPackage-Platform, which is an artifact of Metacello that is not > all that > relevant to a user wanting to understand the system. > > >From the naive user perspective, if I'm exploring from the top > level of the > system, I want to see things like: > - CodeImport > - Collections > - Compiler > > >From this perspective, the 14 entries for Collections, multiplied > by a few > dozen top-level categories make the list unwieldy and only > marginally less > daunting than the flattened list we used to have (see > http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two > ): > <http://forum.world.st/file/n4726287/Picture_1.png> > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 2, 2013

Re: [Pharo-dev] Nautilus Tree

by Goubier Thierry

Le 29/11/2013 17:20, Sean P. DeNigris a Ã©crit : > Sean P. DeNigris wrote >> I noticed that right now, separate packages within the same project are >> not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they >> will be siblings in the tree, instead of both under MyProject. It seems >> like it would be more useful to have >> - MyProject >> - Core >> - Platform >> in the tree > > Bump... thoughts? I've done that a while ago. But not in Nautilus. Find it very convenient. Focused browsing, can forget most of the system around my workset without effort. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 2, 2013

Re: [Pharo-dev] WhatsUp from: 2013-12-02 until: 2013-12-15

by Esteban Lorenzano

On Mon, Dec 2, 2013 at 7:00 AM, <seaside(a)rmod.lille.inria.fr> wrote: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS > - basically, fighting with bugfixes. - last minute integrations to move to beta. > > ### What's next, until 2013-12-15 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > - move to beta. - more bugfixing. - some work on the vm - some work on the association site > > (*) we'll be expecting results by then ;) > >

Dec. 2, 2013

WhatsUp from: 2013-12-02 until: 2013-12-15

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-12-15 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Dec. 2, 2013

Re: [Pharo-dev] Some squeaksource.com updates

by Sean P. DeNigris

David T. Lewis wrote > The welcome page for http://squeaksource.com has been updated... The > policy of disabling new project creation remains in effect. Thanks! It is good that so much of our history will remain accessible... "create any number of projects to host on our server" should probably be removed ----- Cheers, Sean -- View this message in context: http://forum.world.st/Some-squeaksource-com-updates-tp4726613p4726623.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] I'd say Pharo is fitting the bill for me. What would you love it to have?[SEC=UNCLASSIFIED]

by kilon alios

Yeah and there many tools to to help you out. For example take a look at phonegap. Became so popular for ios and android apps that now are owned by Adobe. So there is definetly a big market you can exploit. Another one is Titanium. Because they are all javascript amber can play with all of them so there is huge potential. Î£ÏÎ¹Ï 2 ÎÎµÎº 2013 1:29 Ï.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Stephen Taylor" < stephen.taylor(a)bom.gov.au> ÎÎ³ÏÎ±ÏÎµ: > On Mon, 2013-12-02 at 01:11 +0200, kilon alios wrote: > > Amber can do this for you including the debugging ! I know its not > > quite Pharo but you have the added advantage that it can run on > > Android and anything with a browser capable of Javascript. > > > A good point, and I've been meaning to get to grips with Amber. > > I was going to say "but I can't put a JavaScript app into the App Store > to sell", but a bit of googling makes it look like it's possible, if a > bit circuitous. Interesting... > > > > cheers, > > > > Steve > > >

Dec. 2, 2013

Re: [Pharo-dev] I'd say Pharo is fitting the bill for me. What would you love it to have?[SEC=UNCLASSIFIED]

by Stephen Taylor

On Mon, 2013-12-02 at 01:11 +0200, kilon alios wrote: > Amber can do this for you including the debugging ! I know its not > quite Pharo but you have the added advantage that it can run on > Android and anything with a browser capable of Javascript. A good point, and I've been meaning to get to grips with Amber. I was going to say "but I can't put a JavaScript app into the App Store to sell", but a bit of googling makes it look like it's possible, if a bit circuitous. Interesting... cheers, Steve

Dec. 2, 2013

Re: [Pharo-dev] I'd say Pharo is fitting the bill for me. What would you love it to have?[SEC=UNCLASSIFIED]

by kilon alios

Amber can do this for you including the debugging ! I know its not quite Pharo but you have the added advantage that it can run on Android and anything with a browser capable of Javascript. On Mon, Dec 2, 2013 at 1:00 AM, Stephen Taylor <stephen.taylor(a)bom.gov.au>wrote: > This is probably outside what the core Pharo demographic is looking for, > but this is what I want for Christmas: > > I'd like to be able to program in Pharo on my desktop/laptop and then > with one click deploy to an iOS device. > > Bonus points if I could then debug on the iOS device. > > I would also like Santa to bring me a pony. > > > > > cheers, > > > Steve > > >

Dec. 2, 2013