January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Marcus Denker

On 09 Jan 2014, at 13:59, kilon alios <kilon.alios(a)gmail.com> wrote: > yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow. > > And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :) > > I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :) > A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*. Marcus

Jan. 9, 2014

[Pharo3] Issues "for review" and "for integration" empy

by Marcus Denker

â¦ so we finally managed to have no issues anymore that are -> fix review needed + pre-check by the monkey -> fix to integrate Wow.. that never happened before ;-) Marcus

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by kilon alios

yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow. And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :) I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :) On Thu, Jan 9, 2014 at 2:43 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > On 9 January 2014 12:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 9 January 2014 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 09 Jan 2014, at 11:11, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> I was the one that worked on CMD+L dialog. I posted my slice here and it >>> was discussed. I tried to implement undo, but trying to understand undo was >>> a pain in the ass. >>> >>> >>> I reviewed it and you are not to blame: A key combination that *loses >>> code* is not acceptable, and as we discussed in the past, this >>> change was needed and good. >>> >>> Yes, and i agreed on that. >> My only complaint is that instead of making things work, we reversed it >> and made things even worse. >> >> >>> The people who use the (undocumented!) cmd-L can easily get rid of the >>> warning by implementing Undo. >>> >>> how many modern editors document that pressing home key will move cursor >> to beginning of line? or pressing cmd-v will paste things from clipboard? >> i do not think this is a good criteria to disable feature(s) only because >> they either not documented properly or that someone has no idea it exists. >> > > yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that > its usefulness become very low. > because before i knew that i can type any garbage in any editor window and > undo all with single keystroke, > and now i have to be interrupted with yes/no popup. > > Can i ask, why consoles do not ask you are you sure you want to face > consequences of you pressed ctrl-c? > > > Undo works for ctrl-c. Fo ctrl-l it does not. > > (I really wonder why we have this dissuasion: It was already last time > said that if the key combination removes > code *without a change to get it back* it needs to warn, if people do not > like the warning they should > a) implement undo for ctrl-l > b) remove the warning. > > Marcus >

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 13:51, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > 2014/1/9 kilon alios <kilon.alios(a)gmail.com> > >> Photoshop well deserves its monopoly >> > > I am of the opinion that nothing deserves a monopoly. > > >> and my right to think that Photoshop GUI should be taught in seminars and >> lectures about GUI design. >> > > >> PS did not earn its monopoly by accident or marketing, its there because >> artists just love it. >> > > It probably owes more to the sheer number of pirate photoshops that are > out there, creating a "fan base". ThatÂ´s again an opinion, however I do > know quite a bunch of people who having been swearing by photoshop for > quite a bunch of years, yet theyÂ´ve never owned a license, even when using > it for business purposes. > > And you are debating about whether we should have confirm dialogs or not. >> The way I see it , there is so many issues you have to address even before >> worrying about this. >> > > I fail to see the relevance of all the other "many issues" in finding a > solution to this problem. Given that Igor uses Pharo constantly (or so I > guess), he may very well wish for it to adapt to his workflow, and that > should at least be as legitimate a concern as you wanting it to adapt to > yours. > > In my opinion, it should be up to the users to decide whether they need > their hands held or not, if thereÂ´s such a possibility. Some users will be > more comfortable with the software babysitting them, and others prefer > learning the hard way. Some users happily delete files relying on a recycle > bin, others think hard if they want something deleted before actually doing > it. I see no reason to conciously impose one over the other, given the > opportunity to have both. > > amen, bro! > Cheers, > Sergi > > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Sergi Reyner

2014/1/9 kilon alios <kilon.alios(a)gmail.com> > Photoshop well deserves its monopoly > I am of the opinion that nothing deserves a monopoly. > and my right to think that Photoshop GUI should be taught in seminars and > lectures about GUI design. > > PS did not earn its monopoly by accident or marketing, its there because > artists just love it. > It probably owes more to the sheer number of pirate photoshops that are out there, creating a "fan base". ThatÂ´s again an opinion, however I do know quite a bunch of people who having been swearing by photoshop for quite a bunch of years, yet theyÂ´ve never owned a license, even when using it for business purposes. And you are debating about whether we should have confirm dialogs or not. > The way I see it , there is so many issues you have to address even before > worrying about this. > I fail to see the relevance of all the other "many issues" in finding a solution to this problem. Given that Igor uses Pharo constantly (or so I guess), he may very well wish for it to adapt to his workflow, and that should at least be as legitimate a concern as you wanting it to adapt to yours. In my opinion, it should be up to the users to decide whether they need their hands held or not, if thereÂ´s such a possibility. Some users will be more comfortable with the software babysitting them, and others prefer learning the hard way. Some users happily delete files relying on a recycle bin, others think hard if they want something deleted before actually doing it. I see no reason to conciously impose one over the other, given the opportunity to have both. Cheers, Sergi

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 13:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > On 9 January 2014 12:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 9 January 2014 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 09 Jan 2014, at 11:11, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> I was the one that worked on CMD+L dialog. I posted my slice here and it >>> was discussed. I tried to implement undo, but trying to understand undo was >>> a pain in the ass. >>> >>> >>> I reviewed it and you are not to blame: A key combination that *loses >>> code* is not acceptable, and as we discussed in the past, this >>> change was needed and good. >>> >>> Yes, and i agreed on that. >> My only complaint is that instead of making things work, we reversed it >> and made things even worse. >> >> >>> The people who use the (undocumented!) cmd-L can easily get rid of the >>> warning by implementing Undo. >>> >>> how many modern editors document that pressing home key will move cursor >> to beginning of line? or pressing cmd-v will paste things from clipboard? >> i do not think this is a good criteria to disable feature(s) only because >> they either not documented properly or that someone has no idea it exists. >> > > yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that > its usefulness become very low. > because before i knew that i can type any garbage in any editor window and > undo all with single keystroke, > and now i have to be interrupted with yes/no popup. > > Can i ask, why consoles do not ask you are you sure you want to face > consequences of you pressed ctrl-c? > > > Undo works for ctrl-c. Fo ctrl-l it does not. > > i meant ctrl-c in console. try running pharo from console, and press ctrl-c *in console*. > (I really wonder why we have this dissuasion: It was already last time > said that if the key combination removes > code *without a change to get it back* it needs to warn, if people do not > like the warning they should > a) implement undo for ctrl-l > b) remove the warning. > > good luck with implementing undo for console's ctrl-c :) > Marcus > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Marcus Denker

On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 12:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 11:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 09 Jan 2014, at 11:11, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass. >> > > I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this > change was needed and good. > > Yes, and i agreed on that. > My only complaint is that instead of making things work, we reversed it and made things even worse. > > The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo. > > how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? > i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists. > > yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. > because before i knew that i can type any garbage in any editor window and undo all with single keystroke, > and now i have to be interrupted with yes/no popup. > > Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c? Undo works for ctrl-c. Fo ctrl-l it does not. (I really wonder why we have this dissuasion: It was already last time said that if the key combination removes code *without a change to get it back* it needs to warn, if people do not like the warning they should a) implement undo for ctrl-l b) remove the warning. Marcus

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 12:59, kilon alios <kilon.alios(a)gmail.com> wrote: > Photoshop well deserves its monopoly, and its GUI played a vital role in > it. Its your right to think that Photoshop is not good and my right to > think that Photoshop GUI should be taught in seminars and lectures about > GUI design. > I dont use Photoshop I use GIMP. I prefer to support open source. GIMP's > GUI is bad, it was very bad , fortunately it has improved a bit. But there > are like thousand of opinions out there that will show you what average > user thinks about PS. PS did not earn its monopoly by accident or > marketing, its there because artists just love it. > > You say you care about GUI , can you show me how exactly you care ? > Because I love coding in pharo and I like the GUI, but its not very good , > but its better than other IDEs. Pharo has barely changed GUI wise, sure it > has Athens and Spec and Glamour and many other nice things, but the GUI > itself is still very similar to squeak. For example monticello, common > repos for all packages , really ? System browser , only recently got a tab > system. Why a three panel should be forced down my throat, i want to > maximise the view for seeing the code itself. Fullscreen not working as > fullscreen in macos which is the dominant platform of pharo. Nautilus has > strange blue box appearing for packages . A billion of windows to browse > through classes and methods is that good GUI design. > > I know you worked on Nativeboost and Athens but I have seen no GUI work > from you. I love your work and thank you but I am surprised to hear you say > that you care about GUI. > > And here a list of things i did over long time polishing different aspects, which one way or another related to GUI: - skip over white space - rectangle refactoring and introducing Margin(s) - work on new system events and event handling - prevent VM from stealing active OpenGL context on Macs - various fixes to Freetype. - speedup rendering - get rid of bogus shadow & rounded corners to do it right. - oh damn.. there's so many little things i barely remember what i did. and Athens.. for what other reason, you think we would be developing Athens, other than make a quality change which will affect our GUIs at the end? guess what i been worked on for last half of year? on text editor! and there's still a lot to do left. and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events. I don't know what else i can say to convince you that i do really care about GUI and always was. And you are debating about whether we should have confirm dialogs or not. > The way I see it , there is so many issues you have to address even before > worrying about this. > > so lets fix it.. but not make things worse. > You say that is better to let the baby burn to learn that fire is bad, > Maybe you should let the baby die to learn death is not good. > Death is a good lesson for others. How else you would know that parents who careless enough to let baby die is bad parents, if there's nobody dies? > If I have a tool that is easy to use and another that want to "teach me" > the hard way, I rather go with the easy one. We live in world that makes > life very complex , why make it even more complex than it needs to be ? I > dont need a stupid software to tell me that I need to sit down and learn to > improve. > The whole point is: stupid software should not tell you what you need or not. It should just follow your commands without (re)asking you twice. Software cannot reason whether you pressed key because it was your intent, your typo or your mistake, the best it can do is to remain being stupid and just perform the damn command, without asking asking twice twice. period. period. And sure thing, we should learn from own mistakes, no software could teach us this very simple principle. But then even if you learn an app really well, a bad GUI will always remain > a bad GUI, even if you have found a thousands workarounds and will hinder > your workflow every single day. > > Fully agreed. And this is what should motivate us to improve it. > > On Thu, Jan 9, 2014 at 1:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 9 January 2014 12:11, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> >>> Well, truth be told, the editors are really a pain in the current form. >>> And in some ways are worse than in the past, especially with selection bugs >>> etc. Now, given that we are using principles that date back 30+ years, it >>> is astonishing that we went so far without massive changes. >>> >>> There are efforts ongoing and getting TextEditors "right" is really >>> hard. I really look forward to the new editor and dark theme. >>> >>> Now, yeah, I should move my ass and contribute more to this. Putting >>> bread on the table is getting in my way at the moment, but that's forseen >>> to change soon. >>> >>> (And Photoshop is a pain in the assets as well - GIMP isn't any better. >>> What matters is that one invests time in learning the quirks to get the >>> results. Always like that. Currently working with Varicad for some design >>> project and the UI isn't simple either, see for yourself: >>> >> >> >> yeah.. GUI typically falls victim of too many functionality fighting with >> too little screen space :) >> >> I just want that everyone understands my point: lets not surrender and >> keep making progress. >> yes, we will suffer in the process, but that should serve as a stimulus >> to do things right, instead of doing nothing by reverting everything back. >> I am fully understand and accepting that everyone has own preferences and >> different workflow, and i never assuming that my workflow is the only one >> which should prevail above everyone's else. >> Well except the modal things :P >> >> >> >>> [image: Inline image 1] >>> >>> >>> >>> >>> On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> On 9 January 2014 11:10, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>>> I was the one that worked on CMD+L dialog. I posted my slice here and >>>>> it was discussed. I tried to implement undo, but trying to understand undo >>>>> was a pain in the ass. >>>>> >>>>> And yes Igor I am no pro coder, I code like 30 minutes a day max. I am >>>>> a lawyer that tries to become a pro 2d/3d artist. >>>>> I enjoy coding and an IDE that punishes me for my mistakes does not >>>>> make coding enjoyable for me. >>>>> >>>> >>>> because punishment is a HUGE part of process as one of the stimulus for >>>> learning things you wouldn't learn the other way. Without it, i doubt you >>>> can learn anything at all. >>>> You can give a candy to baby each time it does not try touching fire, >>>> and the only thing which baby will learn is that to get a candy it needs to >>>> pretend that its about to touch fire. >>>> Only after baby will touch it, it can learn why touching it is bad >>>> idea.. no candies will help. >>>> >>>> I think maybe an easy solution is to set all modals to a preference >>>>> setting so they can be easily disabled, thus making everyone happy. >>>>> >>>>> Yes, that could be a way to go. >>>> >>>> >>>>> Igor I will be frank with you, coders have no idea how to design good >>>>> GUIs. They see GUIs as nothing more than an inconvenience and extra coding >>>>> effort from their part. >>>>> >>>> >>>> really? i do not belong to those who think GUI is secondary. A >>>> well-designed GUI is very important for efficient workflow. Same as >>>> well-designed language, like smalltalk is. >>>> >>>> They usually put out the excuse "I am no designer" yet the truth is >>>>> that they dont care because they cant understand the importance of a great >>>>> GUI to the user. Applications like Photoshop are rare example of good GUI >>>>> design. >>>>> >>>> >>>> you lost me on that. I never considered Photoshop as one that has good >>>> GUI design.. >>>> The main merit of Photoshop is that it is killed all other really good >>>> graphics editors and established monopoly. It's easy to say 'we are best' >>>> when there's nothing to compare with. >>>> >>>> >>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Athens SVG Import

by Igor Stasenko

On 9 January 2014 12:54, J.F. Rick <self(a)je77.com> wrote: > 'self changed' logic is the thing that triggers drawing. Before Athens, > various different morphs would register that their part of the screen > needed to be updated with a 'self changed' thing. Then, once a UI cycle, > the sum of the areas needing to be changed was determined and those morphs > within that area would be redrawn. So, you could have a 100 'self changed' > things happening before drawing happens. It seems like with Athens that > each 'self changed' causes a redraw. So, having 25 times as many self > changed messages causes 25 times as many drawing cycles. While Athens is > faster than BitBlt rendering, it may not be 25 times faster. > > Lets make things clear: Athens is responsible for drawing things on canvas. It is not responsible for what you drawing, when and where. Such things is beyond the scope of Athens. So, if there's a bug it could be related to some Morphic glue code (like in AthensWrapMorph etc). That is possible. And so, if you suspecting there's something wrong, look in that direction, and don't loose time trying to fix something in Athens because these things actually belong to morphic. > Cheers, > > Jeff > > > On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 9 January 2014 10:26, J.F. Rick <self(a)je77.com> wrote: >> >>> OK. I've made a little headway in diagnosing the problem. It seems that >>> one culprit is that the "self changed" thing works differently with Athens >>> than previously. Correct me if I'm wrong, but it seems like sending that >>> method immediately causes the canvas to draw. In contrast, before, it just >>> marked that area as needing to be redrawn and then, on an update cycle, it >>> would redraw the total area that changed. I was using a model-view pattern >>> that had 25 components to it. When each got the update command, it seems to >>> have launched the canvas to draw. When I changed it so that only one >>> changed command was given, the interface became immediately much snappier. >>> Adding a factor of 25 to rendering could cause even fast rendering to be >>> quite noticeable. So, it is not an inherent problem with drawing forms but >>> rather one with changing the programming paradigm. Forms are just >>> noticeably slower to draw than vector components and that exacerbated my >>> problem. >>> >>> >> Hmm.. Can you explain me, how Athens is related to that? :) >> >> 'self changed' logic and its handling is related to Morphic and used by >> it. >> there's no way how you can change it by changing something in Athens. >> >> >> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <self(a)je77.com> wrote: >>> >>>> Hmm. Weird. Could it be a linux thing? Bit order or something? Could it >>>> be a transparency issue? Could it be a size of the form? I have forms of >>>> size around 200 x 200. At this point, I haven't numerically investigated >>>> it. I just notice a significant difference in rendering speed as I switch >>>> from forms to SVGs. Perhaps it is having to redraw the entire interface >>>> very often. I'll investigate a bit more when I have some time. >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> >>>> On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 8 January 2014 08:59, J.F. Rick <self(a)je77.com> wrote: >>>>> >>>>>> In good news, I was able to implement the S/s functionality and both >>>>>> of my SVGs now load properly. I'll try some more soon and commit the >>>>>> changes once I have tested it a bit more. >>>>>> >>>>>> In bad news, the cacheing was working properly, so I still suspect >>>>>> that rendering forms as a paint is too intensive to be practical for many >>>>>> applications. I'll try to evaluate it a bit more as I replace forms with >>>>>> SVGs. If the forms are causing the problem, then performance should >>>>>> noticeably increase. >>>>>> >>>>>> >>>>> I just did a little comparison: >>>>> >>>>> | surface time | >>>>> surface := AthensCairoSurface extent: 200@200. >>>>> >>>>> surface drawDuring: [ :canvas| >>>>> canvas setPaint: Color red. >>>>> canvas setShape: (0@0 extent: 100@100). >>>>> time := [ 10000 timesRepeat: [ canvas draw ] ] timeToRun. >>>>> ]. >>>>> time >>>>> 0:00:00:00.115 >>>>> ============= >>>>> >>>>> same as above but with: >>>>> canvas setPaint: (ThemeIcons current backIcon). >>>>> >>>>> time >>>>> 0:00:00:00.093 >>>>> =========== >>>>> >>>>> same as above but with: >>>>> (canvas setPaint: (ThemeIcons current backIcon)) repeat. >>>>> >>>>> time >>>>> 0:00:00:00.956 >>>>> >>>>> as you can see, even in slowest case, the throughput is: >>>>> >>>>> 100*100*10000 = 100'000'000 pixels (texels) per second. >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Jeff >>>>>> >>>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] TDD in Core

by Goubier Thierry

Le 09/01/2014 12:28, Esteban Lorenzano a Ã©crit : > +1 to just add things with appropriate tests. > > in the case of Spec in particular, the problem is that is really hard to have UI testing :( I'd say that Pharo makes it easy to do UI testing. Look, you can test an app by opening a window, eventing it and closing it before the user has even seen the window on screen ? But yes, GUIs have a lot of functionalities and hence are hard to test. > Alsoâ¦ sometimes you break backward compatibility, thatâs inevitableâ¦ and is ok if is for the best (like in the case of Specâ¦ it was to gain ui platform independence). > > but anyway, I do agree that we need to raise our acceptance criteria :) One issue is that even the current test suites do not give me confidence. I just did a refactoring of the announcement stuff in Morphic (12531 and 12598), all tests are green but honestly I know those tests are not testing enough code. (in short, it's : help me for 12598! I'll push a slice and I'd really like people using Nautilus and other GUI heavy stuff to pound on it and report issues) 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

Jan. 9, 2014