- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fogbugz workflow

by btc＠openinworld.com

Camillo Bruni wrote: > it is currently working fine, no? > the "status:review" also matches the "Fix Reviewed by the Monkey" status. > Whoops. Yes it works as expected - I must be going mad. > On 2013-10-17, at 14:39, btc(a)openinworld.com wrote: > >> Thanks Camillo. So if the Shared Filter > Review displays cases waiting for human review, should it be updated to... >> (status:review or status:reviewed) and area:"1. Pharo Image" >> >> cheers -ben >> >> Camillo Bruni wrote: >> >>> The idea would be that the monkey filters out most of the typical bugs and that then >>> a human (other than the submitter) reviews the code manually and puts it fix-to-include ;) >>> >>> On 2013-10-17, at 10:16, Ben Coman >>> <btc(a)openInWorld.com> >>> wrote: >>> >>> >>> >>> >>>> A further query on workflow with FogBugz. >>>> >>>> It seems the Galactic Monkey From Outer Space picks up Cases with status 'Resolved (Fix Review Needed)'. When that is succcessful, what is the next step? Should I being changing the status to 'Resolved (Fix To Include)' myself or is further human review required? >>>> >>>> Referring to >>>> https://pharo.fogbugz.com/default.asp?11835 >>>> >>>> this Case now doesn't appear in any of the Work Needed, Integration nor Review filters. >>>> Hence my query about the next step. >>>> >>>> cheers -ben >>>>

Oct. 17, 2013

Re: [Pharo-dev] default monospaced code font

by Goubier Thierry

Oh, ok, thanks for the explanation. I noticed effectively that switching to Source Sans 10 increased significantly the density (copying the Source Sans font files in /usr/local/share/fonts/ made them visible to Pharo), and that, it solved the MNU on unicode glyphs as well. So all is well with the Source Sans Pro and I'm happy. Thierry Le 17/10/2013 15:22, btc(a)openinworld.com a Ã©crit : > > what with the 2x space? > > Something I like about Source Code Pro is the greater spacing between > identifiers. In comparison, I found DejaVu Sans and Source Sans Pro to > be too dense, especially so with the latter. So I experimented with > doubling the size of that space with the proportional fonts. I just > Search-Replaced <space> with <space-space>, but in an IDE you could use > one of the wider space character like the EN-QUAD [5]. Except the > performance with Unicode versus ascii characters would need to be > checked. I've attached a some more comparisons of identifier spacing. > Sorry I mislead you with the Source Sans Pro 2X-spacing in previous > PDF. You wont get that exactly out of the box without some code changes > to use a wider space character. Check you opinion against the 1X-spacing. > cheers -ben > > [5] http://www.cs.tut.fi/~jkorpela/chars/spaces.html > > > > Goubier Thierry wrote: >> Excellent, I like the comparison a lot! Thanks! >> >> My take is: >> - Unable to like Source Code Pro 9 (and it's so wide); >> - Source Sans Pro 9 has spacing issues (16r, the r is too close) and >> reading issues (it's the worse for the lL|i characters) >> - Source sans Pro 10 is better than 9 (but what with the 2x space?) >> >> Overall, I'd stay with DejaVu Sans 9 based on this sample. In my >> opinion, the best compromise density / readability. >> >> Thierry >> >> Le 16/10/2013 19:56, btc(a)openinworld.com a Ã©crit : >>> Goubier Thierry wrote: >>>> I'd be more impressed if the argument was helping me distinguish >>>> between | and l. >>> >>> Yes. It is designed to do that. Some common failings of monospaced fonts >>> are noted [1] and dealt with. There comment section is also interesting. >>> >>> The attached PDFs are the result of getting the urge to compare a broad >>> coverage of code examples (taken from "Terse Guide to Squeak") against >>> three fonts: >>> * DejaVu Sans 9 point >>> * Source Code Pro [1] [2] 9 point >>> * Source Sans Pro [3] [4] 9 point & 10 point, since the width of 10 was >>> the same as the others at 9. >>> Also attached is the source excel file. >>> >>> cheers -ben >>> >>> [1] http://blogs.adobe.com/typblography/2012/09/source-code-pro.html >>> [2] http://sourceforge.net/projects/sourcecodepro.adobe/files/ >>> [3] http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html >>> [4] >>> http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp >>>> >>>> I'l let you try, then :) >>>> >>>> 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

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

yes, because package names changed (no more 1 rpackage = 1 system category), then the export of sources changed too (not the contents). For example, what was AST-Core-*, now is just AST-Core. Esteban On Oct 17, 2013, at 2:51 PM, Marcus Denker <marcus.denker(a)gmail.com> wrote: > > >> On 17.10.2013, at 13:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> Strange... the commit is already there :) >> > > > too large for the list (7mb) >> https://github.com/pharo-project/pharo-core/commit/39e14deac5f2ad03e2d1b539… >> >>> On 2013-10-17, at 13:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> he... the update is already there, github failed to send the diff info (yet) >>> >>>> On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> >>>> >>>> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>>>> >>>>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>> >>>>>> Are you using MorphTreeMorph? >>>>> yep :) >>>> >>>> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >>>> >>>> I remember having difficulties to understand how to pass and receive objects through drag and drop. >>>> >>>> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >>>> >>>> Thierry >>>> >>>>>> >>>>>> Thierry >>>>>> >>>>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>>>> >>>>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>>>> - multiselection in packages >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>>> On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just important an important change in Pharo. >>>>>>>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>>>>>>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>>>>>>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>>>>>>> >>>>>>>> So, what's the change? >>>>>>>> Now 1 RPackage 0 1 MCPackage. >>>>>>>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>>>>>>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>>>>>>> This change opens the path to remove old PackageInfo, finally :) >>>>>>>> >>>>>>>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>>>>>>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>>>>>>> >>>>>>>> THERE WILL BE BUGS! >>>>>>>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>>>>>>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>>>>>>> >>>>>>>> Please, report any issue around. >>>>>>>> >>>>>>>> Enjoy, >>>>>>>> Esteban >>>>>> >>>>>> -- >>>>>> 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 >>>> >>>> -- >>>> 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 >> >

Oct. 17, 2013

Re: [Pharo-dev] default monospaced code font

by btc＠openinworld.com

> what with the 2x space? Something I like about Source Code Pro is the greater spacing between identifiers. In comparison, I found DejaVu Sans and Source Sans Pro to be too dense, especially so with the latter. So I experimented with doubling the size of that space with the proportional fonts. I just Search-Replaced <space> with <space-space>, but in an IDE you could use one of the wider space character like the EN-QUAD [5]. Except the performance with Unicode versus ascii characters would need to be checked. I've attached a some more comparisons of identifier spacing. Sorry I mislead you with the Source Sans Pro 2X-spacing in previous PDF. You wont get that exactly out of the box without some code changes to use a wider space character. Check you opinion against the 1X-spacing. cheers -ben [5] http://www.cs.tut.fi/~jkorpela/chars/spaces.html Goubier Thierry wrote: > Excellent, I like the comparison a lot! Thanks! > > My take is: > - Unable to like Source Code Pro 9 (and it's so wide); > - Source Sans Pro 9 has spacing issues (16r, the r is too close) and > reading issues (it's the worse for the lL|i characters) > - Source sans Pro 10 is better than 9 (but what with the 2x space?) > > Overall, I'd stay with DejaVu Sans 9 based on this sample. In my > opinion, the best compromise density / readability. > > Thierry > > Le 16/10/2013 19:56, btc(a)openinworld.com a Ã©crit : >> Goubier Thierry wrote: >>> I'd be more impressed if the argument was helping me distinguish >>> between | and l. >> >> Yes. It is designed to do that. Some common failings of monospaced fonts >> are noted [1] and dealt with. There comment section is also interesting. >> >> The attached PDFs are the result of getting the urge to compare a broad >> coverage of code examples (taken from "Terse Guide to Squeak") against >> three fonts: >> * DejaVu Sans 9 point >> * Source Code Pro [1] [2] 9 point >> * Source Sans Pro [3] [4] 9 point & 10 point, since the width of 10 was >> the same as the others at 9. >> Also attached is the source excel file. >> >> cheers -ben >> >> [1] http://blogs.adobe.com/typblography/2012/09/source-code-pro.html >> [2] http://sourceforge.net/projects/sourcecodepro.adobe/files/ >> [3] http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html >> [4] >> http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp >>> >>> I'l let you try, then :) >>> >>> Thierry >> >

Oct. 17, 2013

Re: [Pharo-dev] Fogbugz workflow

by Camillo Bruni

it is currently working fine, no? the "status:review" also matches the "Fix Reviewed by the Monkey" status. On 2013-10-17, at 14:39, btc(a)openinworld.com wrote: > Thanks Camillo. So if the Shared Filter > Review displays cases waiting for human review, should it be updated to... > (status:review or status:reviewed) and area:"1. Pharo Image" > > cheers -ben > > Camillo Bruni wrote: >> The idea would be that the monkey filters out most of the typical bugs and that then >> a human (other than the submitter) reviews the code manually and puts it fix-to-include ;) >> >> On 2013-10-17, at 10:16, Ben Coman >> <btc(a)openInWorld.com> >> wrote: >> >> >> >>> A further query on workflow with FogBugz. >>> >>> It seems the Galactic Monkey From Outer Space picks up Cases with status 'Resolved (Fix Review Needed)'. When that is succcessful, what is the next step? Should I being changing the status to 'Resolved (Fix To Include)' myself or is further human review required? >>> >>> Referring to >>> https://pharo.fogbugz.com/default.asp?11835 >>> >>> this Case now doesn't appear in any of the Work Needed, Integration nor Review filters. >>> Hence my query about the next step. >>> >>> cheers -ben

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Marcus Denker

> On 17.10.2013, at 13:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > Strange... the commit is already there :) > too large for the list (7mb) > https://github.com/pharo-project/pharo-core/commit/39e14deac5f2ad03e2d1b539… > >> On 2013-10-17, at 13:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> he... the update is already there, github failed to send the diff info (yet) >> >>> On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> >>> >>> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>>> >>>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>>> Are you using MorphTreeMorph? >>>> yep :) >>> >>> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >>> >>> I remember having difficulties to understand how to pass and receive objects through drag and drop. >>> >>> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >>> >>> Thierry >>> >>>>> >>>>> Thierry >>>>> >>>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>>> >>>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>>> - multiselection in packages >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>>> On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I just important an important change in Pharo. >>>>>>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>>>>>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>>>>>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>>>>>> >>>>>>> So, what's the change? >>>>>>> Now 1 RPackage 0 1 MCPackage. >>>>>>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>>>>>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>>>>>> This change opens the path to remove old PackageInfo, finally :) >>>>>>> >>>>>>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>>>>>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>>>>>> >>>>>>> THERE WILL BE BUGS! >>>>>>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>>>>>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>>>>>> >>>>>>> Please, report any issue around. >>>>>>> >>>>>>> Enjoy, >>>>>>> Esteban >>>>> >>>>> -- >>>>> 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 >>> >>> -- >>> 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 >

Oct. 17, 2013

Re: [Pharo-dev] Fogbugz workflow

by btc＠openinworld.com

Oct. 17, 2013

Re: [Pharo-dev] Spec error

by Sean P. DeNigris

Thanks -------- Original message -------- From: "Benjamin Van Ryseghem-2 [via Smalltalk]" <ml-node+s1294792n4715238h66(a)n4.nabble.com> Date: 10/17/2013 6:02 AM (GMT-05:00) To: "Sean P. DeNigris" <sean(a)clipperadams.com> Subject: Re: Spec error Fixed:Â https://pharo.fogbugz.com/default.asp?11916 Ben On Oct 16, 2013, at 9:50 PM, Sean P. DeNigris <[hidden email]> wrote: I manually fed in an instance of by changing the code to: Â Â actionToPerformWithSelector: selector arguments: args | instance | instance := spec instance. instance = #DialogWindowSpec ifTrue: [ instance := SpecDialogWindow new ]. ^ instance perform: selector withArguments: args But then I got:Â MessageNotUnderstood: ByteSymbol>>changeTableLayout (where the symbol was #Panel) It seems that #actionToPerformWithSelector:arguments: expects "spec instance" to return an actual instance, but is getting Symbols instead. It seems to be a bug in Spec because none of this has anything to do with my code, and if I change "self new openDialogWithSpec" to "self new openWithSpec" it opens correctly. On Oct 16, 2013, at 1:01 PM, "Benjamin Van Ryseghem-2 [via Smalltalk]" <<a href="x-msg://2950/user/SendEmail.jtp?type=node&node=4715081&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote: Try replacing it with DlalogWindowModel Ben On Oct 16, 2013, at 5:27 PM, Sean P. DeNigris <<a href="<a href="x-msg://206/user/SendEmail.jtp?type=node&amp;node=4715064&amp;i=0">x-msg://206/user/SendEmail.jtp?type=node&node=4715064&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote: Benjamin Van Ryseghem-2 wrote Without further information, I can not do much more I sent #openDialogWithSpec, and the offending symbol is #DialogWindowSpec ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-error-tp4714069p4715018.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Spec-error-tp4714069p4715064.html To unsubscribe from Spec error, <a href="x-msg://2950/" target="_top" rel="nofollow" link="external">click here. NAML Cheers, Sean View this message in context: Re: Spec error Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Spec-error-tp4714069p4715238.html To unsubscribe from Spec error, click here. NAML ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-error-tp4714069p4715287.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2013

Re: [Pharo-dev] [Moose-dev] [ann] system attraction view

by Alexandre Bergel

> That does sound interesting. So the new (student-based) force algorithm would allow for a 'everything is equal' default, or set a certain class of things as more important than others. Or maybe a hierarchy of things a more important (so, classes most important, then packages, then whatever is left over). Yes > I haven't yet personally figured out how I would apply this yet (even the original use), but I am definitely thinking on it. > > And, yes, if I do find a use, it will probably be outside of software as well. I am really enjoying this toolset known as Moose - both for software analysis, and other business-related analysis. :-) Alexandre > > > On Wed, Oct 16, 2013 at 10:12 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class. > > > > I like the idea, but what do you mean by domain-specific ? > > Do you want to visualize something else than software ? > > The force base layout gives to all the edges and nodes the same value. But maybe, if you can tell that some nodes are more important than other, then the complexity can be significantly reduced. > > The algo can be used for anything that is represented as a graph. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Goubier Thierry

30495 has it? AltBrowser still works, but it looks all disorganized inside the packages :):) Thierry Le 17/10/2013 13:08, Esteban Lorenzano a Ã©crit : > he... the update is already there, github failed to send the diff info (yet) > > On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>> >>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>>> Are you using MorphTreeMorph? >>> yep :) >> >> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >> >> I remember having difficulties to understand how to pass and receive objects through drag and drop. >> >> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >> >> Thierry >> >>>> >>>> Thierry >>>> >>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>> >>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>> - multiselection in packages >>>>> >>>>> Esteban >>>>> >>>>> >>>>> On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I just important an important change in Pharo. >>>>>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>>>>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>>>>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>>>>> >>>>>> So, what's the change? >>>>>> Now 1 RPackage 0 1 MCPackage. >>>>>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>>>>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>>>>> This change opens the path to remove old PackageInfo, finally :) >>>>>> >>>>>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>>>>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>>>>> >>>>>> THERE WILL BE BUGS! >>>>>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>>>>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>>>>> >>>>>> Please, report any issue around. >>>>>> >>>>>> Enjoy, >>>>>> Esteban >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> >> >> -- >> 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 >> > > > > -- 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

Oct. 17, 2013