Re: [Pharo-project] [Preview] Help System with new model
yes this was my gut feeling too. What I like with method annotation is that we can get people writing executable examples. Once I discussed with lukas about tests and to me there is a difference between writing tests for coverage and for public consumption. For public consumption you write meaningful api sequence, mini scenario. Stef On Apr 8, 2010, at 11:49 PM, Michael Roberts wrote: Torsten, i appreciate the thought you are putting in. I just wonder if the definition of the help (the raw content) should also be bound up with the definition of the overall structure? I also wonder if I want to bend the help system in a way that it is not intended. For me i want something that is like python doc strings, and the great python package documentation available, ... but in a more smalltalk in-image manner. So that's why i think of it in terms of annotations. Having the help be in its own help class, on the class side, without any real behavior is a design smell to me. I don't really like heavy class-side programming; the class doesn't really offer any behaviour or scale across the image. I guess i want to see docs spread across the system. you want them central? to me the classes are really just annotations, apart from as you say needing to provide the role of structure for the nested content. my use case is that the documentation must be next to the code it is documenting. the network package is a good example. Since the API is in a state of flux, and no one knew how the 'new' api was supposed to work, it could really benefit detailed documentation for each version of pharo. it will change likely for each major version. the docs need to be in the package. fine, we can have the requisite 2 classes already in the image. that is ok. but it would be better to have the doc content on the actual system classes themselves. Like NetNameResolver. and Socket, etc. so i either have to have my custom class reference them, in some imperative manner, or i need to build a builder.. or something. I had imagined it would be possible to have standard places/hooks for packages and classes, where annotations would go. for example like stef says we could pull out the class comment. also, i imagine if documenting the system, in a system wide manner, was successful we would have lots of doit expressions. some mashup between workspaces, profstef, and hypertext. in that case it would be nice to somehow link doc expressions that are really little test assertions together, so we can actually test the docs to make sure that they validate against the system code. I think the SBE/PBE latex sources had this idea in them. And Adrian K has posted examples of these nice extensions to sunit that read very well. I would like that feeling somehow integrated, otherwise we won't be able to maintain the sanity of our docs either. so i guess i'm kinda with stef's comments later in this thread. but anyway, we start with zero in-image documentation. for me we must just have a doc system that scales. i really want to see the docs in the packages, not in a single central package. we'll just have to see how it plays out. i don't want to take away from building a 'help system' that would let you provide F1 style help for an actual application - we just desperately need system level documentation to take Pharo to the next level. I guess I see no need for defining inter-help structure because I think for system level docs it can be entirely derived. each package, class, method can all be annotated in a consistent manner. programming examples could be attached to classes in a standard manner. you could then provide a browser giving A-Z, hierarchy, package, classes, search, index, etc views on these annotations. This is not what you are trying to do with your help system, but i see this as a subset of the intent and a lot of the logic already there. i'm not sure if i'm making any sense... cheers, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
thanks! PS: I will integrate some other fixes when back to the garage later today Got stuck on the highway without gaz :) ... yesterday. David, Lukas, whomever else it may concern. Of course I turned out to be (partly) wrong when looking into it. Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating... Try the attached code, and you should get better results. (you probably want to use smoothing 1 if displaying text with rotation other than a multiple of 90 degrees). This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window) Cheers, Henry FormCanvas-transformByclippingToduringsmoothing.st___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
Thanks lukas Yes the code on the fly is terrible :) Fernando has been working on new version of textEditor and I will integrate them in 1.1 (with some bugs left) stef * Single/multi-line popups - when you're extracting a method via refactor source, you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click ok. It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names? Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an unknown variable popup, choose define new class, click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - refactor source-extract method should be a single-line popup - and, define new class-edit class definition should be a multi-liner. I 100% agree on this, class definition from within the editor totally sucks. Unfortunately this is part of the compiler, not the browser so it requires a change to the parser. I propose the fix below, that also avoids the extra question of asking for the category name. This is unnecessary as it can be edited afterwards in the class definition anyway. http://code.google.com/p/pharo/issues/detail?id=2286 Name: Compiler-LukasRenggli.208 Author: lr Time: 9 April 2010, 8:23:45 am UUID: e0f99e58-08ce-46da-839d-88947b66d668 Ancestors: Compiler-StephaneDucasse.207 - simplify and improve the user experience for class definition while compiling a method Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
Hi Sean, Thanks a lot for the valuable feedback! On Apr 9, 2010, at 05:57 , Sean P. DeNigris wrote: I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with. And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing good ideas i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute? Normally I would do both. If you have code, commit it and create a ticket (not only for bugs but also for features). Then announce it in the mailing list. Since many people are busy, sometimes you don't get a response immediately, especially if it requires somebody loading the code and trying it out. In this case just send a reminder and explicitly ask people for feedback. For the list of suggestions you gave, you may want to wait for other feedback and then create single issues in the tracker for those that other people feel should be changed. Cheers, Adrian [...] ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
On Apr 9, 2010, at 5:57 AM, Sean P. DeNigris wrote: I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with. And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing good ideas i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute? Yes! We are open to a lot of suggestions. For example in 1.1 the way you define method category is waayyy better. Check it you will see (even if there is a small bug). Suggestions: * Why shift for meta? On a Macbook (with one button), it's awkward to press shift+alt+click, and also disorienting to go back and forth from Squeak which is just alt+click. Is there a reason to not keep the convention? I do not remember. What we did was to stop the halos popping up plague. You can get halos but only when you want. * what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually… Certainly not a big deal, but weird. I though of a few possible fixes: People already reported that to me informally A bug fix would be good. Can you open or check if there is bug entry? - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click) * bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow. sound like a good idea. suggestion: repost a mail with that title. open a bug entry. make noise so that ui aware people get a look :) * new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is. Good point. Same process. chekc the realstateAgent class * Single/multi-line popups - when you're extracting a method via refactor source, you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click ok. Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an unknown variable popup, choose define new class, click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - refactor source-extract method should be a single-line popup - and, define new class-edit class definition should be a multi-liner. It sucks I will integrate lukas changes. Thanks for an awesome environment, and I will continue to contribute any way I can :) Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1799044.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
On Apr 9, 2010, at 8:26 AM, Lukas Renggli wrote: * Single/multi-line popups - when you're extracting a method via refactor source, you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click ok. It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names? You could specialize the EntryFieldMorph Stef integrated in 1.1. It's a single line entry field, that when accepted with Character cr or escaped, announces it via Announcements. I've been wanting to implement a specialized SelectorWithArgumentsEntryField also, that heavlily uses the refactoring engine when the user enters input. Its in my todo list, but still couldn't find the right time. Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
Hi fernando I will integrate your changes + lukas and a couple of toher later today. Stef On Apr 9, 2010, at 9:45 AM, Fernando olivero wrote: On Apr 9, 2010, at 8:26 AM, Lukas Renggli wrote: * Single/multi-line popups - when you're extracting a method via refactor source, you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click ok. It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names? You could specialize the EntryFieldMorph Stef integrated in 1.1. It's a single line entry field, that when accepted with Character cr or escaped, announces it via Announcements. I've been wanting to implement a specialized SelectorWithArgumentsEntryField also, that heavlily uses the refactoring engine when the user enters input. Its in my todo list, but still couldn't find the right time. Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
Pay attention there is a #haltOnce in the code. Also there is something wrong with the line endings in the change-set. The change solves the problem with the vertical text in eCompletion, so this is very cool. However it also breaks some window refreshing, see attached screenshot. Lukas On 9 April 2010 08:51, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks! PS: I will integrate some other fixes when back to the garage later today Got stuck on the highway without gaz :) ... yesterday. David, Lukas, whomever else it may concern. Of course I turned out to be (partly) wrong when looking into it. Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating... Try the attached code, and you should get better results. (you probably want to use smoothing 1 if displaying text with rotation other than a multiple of 90 degrees). This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window) Cheers, Henry FormCanvas-transformByclippingToduringsmoothing.st___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch attachment: Screen shot 2010-04-09 at 11.13.42 .png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
funny way to type code. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
I don't write code like this. Rotating a window is just a good test to see if works, because it calls all kind of different code. If you rotate a more complex window than a workspace, my system hangs btw. So there must be other stuff broken there. Lukas On 9 April 2010 11:20, Stéphane Ducasse stephane.duca...@inria.fr wrote: funny way to type code. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
On Apr 9, 2010, at 11:28 AM, Lukas Renggli wrote: I don't write code like this. It was a joke :) but I really like the visual effect Rotating a window is just a good test to see if works, because it calls all kind of different code. If you rotate a more complex window than a workspace, my system hangs btw. So there must be other stuff broken there. oops with the fix too? Lukas On 9 April 2010 11:20, Stéphane Ducasse stephane.duca...@inria.fr wrote: funny way to type code. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [Preview] Help System with new model
Hi Stef and Michael, your responses have shown me that I may have not clearly communicated what is possible and what my goals are. It has also shown me that you mainly talk about the help system as to provide API help or reference documentation, which is possible but was not my main goal. So lets explain it in more detail: We have two separate cases/kind of help: A. Help for the system in front of you (SystemHelp) Documentation of a tool or a process (General Tool Help/Tutorials/F1 Help/Written Book) B. Help on how the system in front of you is implemented (SystemReference) Documentation of classes and methods, examples as in any other Smalltalk/Dev system (API Help/Class comments/Method comments) Regading A - Help for the system in front of you (SystemHelp): Just evaluate HelpBrowser openOn: SystemHelp or just HelpBrowser open My initial goal was to do have F1 Help as in most other IDE's so a help browser opens to display a complete help book with a full written Tutorial on how the Monticello Browser works. Or how one is able to work with Metacello or what object oriented programming is all about, or how one is able to create a project on Squeaksource. We could even have an ASCII version of Pharo by Example, ... This kind of help doesnt even have to be related to stuff that is in the image. You could provide books on gardening and read them in the image if you like. ;) This kind of help could have been external in files or on a webpage, - but I since my goal was that one can read/display it also within the image I JUST (AB)USE classes and class hierarchies to store the help book contents. This also allows to manage the books and contents with usual Smalltalk tools and (if required) also to provide dynamic content. But typically these classes just provide the help contents and it is intended that they have no behavior! I dont want this to be limited to tutorials or tool help. Think of a case where one writes a card playing game with Pharo and want to provide a help book to the commercial end user explaining the game. I know it is much more effort to write such documentation - but for the dev-image/pharo tools we may provide at least simple books to explain basic things like the project itself, license, how to get started with the tools, ... Since this kind of help is typically structured like a real book there is the CustomHelp class allowing you to map your books structure directly to subclasses. If you write such a class mapped book you want to keep the book/subbooks/pages together and not spread around the image. And I call this System help since it shows you help to explain the system that is in front of you (either Pharo or the commercial card game). When you run HelpBrowser open this SystemHelp (see the according class SystemHelp) just collects all direct subclasses of CustomHelp as root books. Nothing more. So if you want to have your book appear in this system wide help you: 1. either store your book contents in the CustomHelp hierarchy (this is the typical case where you map the book to subclasses, see class HelpOnHelp or PharoHelp for example) 2. or provide a direct/indirect CustomHelp subclass to just define the book to appear in the system help but get the contents from other sources (see class PharoAPIHelp which allows us to provide the whole class API in the Pharo book) Especially the second option allows you to mix dynamic content like API Help into these system help books. Just open the chapter API Reference in the Pharo book when you have the package Pharo-Project-Help loaded. More on this later. Dont get me wrong, it is alway possible to open the Help browser on any object that is able to convert itself into a HelpTopic instance using #asHelpTopic HelpBrowser openOn: myObjectWhoCanBeConverted but it is necessary to have a subclass of CustomHelp it appears in the default system wide help (SystemHelp) when you open the browser using the menu or by HelpBrowser open. So CustomHelp is the entry point here, nothing more! To summarize: - A. is intended for whole books and a system wide help system - A. requires the class CustomHelp - to define at least the root books appearing in this System help - to allow mapping a book structure directly to a class hierarchy (and keep this book with its subbooks together) Providing such a help was the original goal of the help system which is now fully possible. Still plain ASCII and without support for markup, images, ... yet - but usable. Regarding B - Help on how the system in front of you is implemented (SystemReference): == Just evaluate HelpBrowser openOn: SystemReference Beside A. there is also Documentation of classes and methods as we have in any other programming
Re: [Pharo-project] [Vm-dev] Fwd: loading library with FFI fails (was Linux vm: assertions and strategy)
Ian, I cannot ignore what was never delivered to me - you might want to reconsider your logic in this connection. You might also note that #moduleName can check the OS, so it will never work on Windows is just plain wrong. Later in the day I will revert to your vm and try 'odb' - I will admit to being less than optimistic, especially given what I ignored - make that never received. Bill -Original Message- From: Ian Piumarta [mailto:i...@vpri.org] Sent: Friday, April 09, 2010 2:25 AM To: Schwab,Wilhelm K Cc: laurent laffont Subject: Re: [Vm-dev] Fwd: loading library with FFI fails (was [Pharo-project] Linux vm: assertions and strategy) On Apr 8, 2010, at 11:40 PM, Ian Piumarta wrote: I have no idea. I sent email to Bill with a suggestion but he ignored me. I therefore have no information about whether there is something funny in his Linux installation or whether there is a real problem in the VM (which appears to work fine for me). I could be completely wrong about this. If so, please disregard. But... From the patch I am inferring that the odbc library specifies module: '/usr/lib/libodbc.so'. This would indeed be a problem for three reasons. 1. Mine might be in /usr/local/lib, or might be a personally-compiled version to fix some issue with the system version. In either case I'm screwed. 2. I might be using Darwin, in which case '/usr/lib/libodbc.dylib' might be the only thing that would work -- or even '/System/Library/ Frameworks/ODBCFramework/Libraries/libodbc.dylib'. Same comment as before. 3. It will never work on Windows, even if some day Windows supplies an 'odbc.dll' that is 100% compatible with the Linux one. The usual way for the plugin to specify this library would be module: 'odbc' which should work perfectly in all the above cases using the latest VM (and explains why I could not reproduce the problem using a simpler test case). I'm happy to modify the VM to cater for this specific situation of an over-specified library name, but the real solution would be fix the primitive declarations in the ODBC plugin. Cheers, Ian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
If you rotate a more complex window than a workspace, my system hangs btw. So there must be other stuff broken there. oops with the fix too? Yes, with and without the change. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
On Apr 9, 2010, at 11:40 38AM, Stéphane Ducasse wrote: On Apr 9, 2010, at 11:28 AM, Lukas Renggli wrote: I don't write code like this. It was a joke :) but I really like the visual effect Rotating a window is just a good test to see if works, because it calls all kind of different code. If you rotate a more complex window than a workspace, my system hangs btw. So there must be other stuff broken there. oops with the fix too? Yes. The fix was for which draw mode is used, and nothing else. The transformBy: method still creates a new Form of extent and depth same as the Tranformation each draw call, so it gives the GC a real workout. Sometimes this manifests as system hangs, others as a constantly higher CPU usage. (depending on how large your transformed morph is) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Vm-dev] Fwd: loading library with FFI fails (was Linux vm: assertions and strategy)
Ian, I will try what you want. -Original Message- From: Ian Piumarta [mailto:i...@vpri.org] Sent: Friday, April 09, 2010 5:42 AM To: Schwab,Wilhelm K Cc: laurent laffont; Pharo-project@lists.gforge.inria.fr Subject: Re: [Vm-dev] Fwd: loading library with FFI fails (was [Pharo-project] Linux vm: assertions and strategy) Hi Bill, On Apr 9, 2010, at 3:24 AM, Schwab,Wilhelm K wrote: I cannot ignore what was never delivered to me - you might want to reconsider your logic in this connection. My initial assumption appears to be incorrect and so the suggestion I sent not to be relevant to debugging your problem. But the original is attached in case you care. It seems something between you and me is unreliable in delivery or in spam detection. You might also note that #moduleName can check the OS, so it will never work on Windows is just plain wrong. My mistake. The Unix moduleName should be 'odbc' unless there's a good reason for it not to be. Later in the day I will revert to your vm and try 'odb' Recompile from source. My best attempt at a fix for your issue is in the repo. - I will admit to being less than optimistic, especially given what I ignored - make that never received. Well now that your mailer likes me, why not try to be happy to work with me to resolve this rather than assuming my attempts are futile and in vain? Cheers, Ian From: Ian Piumarta Date: April 7, 2010 11:56:14 AM PDT To: Schwab,Wilhelm K bsch...@anest.ufl.edu Subject: Re: [squeak-dev] RE: Linux 3.11-3 vm and shared libraries Received: (qmail 20182 invoked from network); 7 Apr 2010 18:56:15 - Received: from dsl092-038-093.lax1.dsl.speakeasy.net (HELO [10.0.1.2]) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for bsch...@anest.ufl.edu ; 7 Apr 2010 18:56:15 - Message-Id: 70021dc8-9a49-48c1-b26f-6e75820ed...@speakeasy.net In-Reply-To: a93938cc72687245835ac0be10199f7c7b73c...@hsc-cms01.ad.ufl.edu Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) References: a93938cc72687245835ac0be10199f7c7b73c...@hsc-cms01.ad.ufl.edu a93938cc72687245835ac0be10199f7c7b73c...@hsc-cms01.ad.ufl.edu Bill, On Apr 7, 2010, at 10:34 AM, Schwab,Wilhelm K wrote: It is one thing for my hacked together .so to avoid detection due to some mistake on my part If your .so is in the library search path then it should be found. If your .so contains unresolved references then they should be reported on the console when it fails to load. has anyone tried ODBC on Linux with the new vm? It's sitting in /usr/ lib like it has always been; the vm should find it, right? Yes it should, but try setting your LD_LIBRARY_PATH=/lib:/usr/lib and running the VM. I think there is something wrong with the library searches in 3.11-3. Just different, and a lot more predictable: From: Ian Piumarta piuma...@gmail.com Date: September 16, 2009 7:36:01 PM PDT To: The general-purpose Squeak developers list squeak-...@lists.squeakfoundation.org Subject: 3.11.3.2135 for Unix [...] NOTE: FFI libraries are no longer searched for in every single nook and cranny, which means you might have to set LD_LIBRARY_PATH (or your local equivalent) for FFI-based programs to work properly. Cheers, Ian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Communication with VM guys (part one)
Hi guys I will send a following mail. We should probably synthetize and put them some summary on the web. Stef Begin forwarded message: From: Ian Piumarta i...@vpri.org Date: April 9, 2010 11:43:33 AM GMT+02:00 To: laurent laffont laurent.laff...@gmail.com Cc: stephane ducasse stephane.duca...@free.fr, stephane ducasse stephane.duca...@gmail.com Subject: Re: [Vm-dev] Fwd: loading library with FFI fails (was [Pharo-project] Linux vm: assertions and strategy) Hi Laurent, I've just seen you reply me in private. Do you mind if I forward your mail to Pharo VM mailing lists, to see how we can improve communication and collaboration between projects ? I don't want to start a counterproductive flame war, I hate this, so maybe we can write another mail which doesn't offense people ? Maybe you have ideas on this ? How about we just say this... It seems there is a complete lack of communication within the Pharo community regarding the virtual machine and its development/support. VM development and support (including bug reports and fixes) are discussed on the vm-dev mailing list. Both Pharo users and Squeak users are equally welcome there (and both communities should avoid discussing VM problems on their respective developer lists, since the people who should see those VM bug reports are more likely reading vm-dev than the other lists). Problems that appear to be platform-independent should always be reported to the vm-dev list. Problems specific to a particular platform should be sent to the maintainer of the platform whose e-mail address is included in the release notes or in the download area on squeakvm.org. Nobody could be offended by that? :) Cheers, Ian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Communication with VM guys (part two)
Begin forwarded message: From: Ian Piumarta piuma...@speakeasy.net Date: April 9, 2010 12:35:16 PM GMT+02:00 To: stephane ducasse stephane.duca...@gmail.com Cc: Squeak Virtual Machine Development Discussion vm-...@lists.squeakfoundation.org Subject: Re: [Vm-dev] Questions, communication and process Hi Stef, On Apr 9, 2010, at 2:23 AM, stephane ducasse wrote: - How do people report problems? Just sending an email in the mailing-list is enough? Here are the options, necessarily biased towards my preference which is to try to avoid having to poll for outstanding issues. If it's a general problem of installation or bizarre behaviour that differs between platforms, ask for help on the Squeak VM mailing list. http://lists.squeakfoundation.org/mailman/listinfo/vm-dev Pharo and Squeak users are EQUALLY WELCOME to report VM issues on that list. Squeak has several people who regularly take the time to forward things from squeak-dev to vm-dev when appropriate. You might want to encourage the same thing on the Pharo list. I know for a fact that there are several vm-dev subscribers that monitor the Pharo list. (You might want to make it clear that Pharo uses the Squeak VM too. This does not necessarily appear to be universally understood.) If it's a Unix-specific problem that you think might be a bug, report it to the above mailing list AND send me email. Fixes are best submitted as complete modified files (not 'diffs'). (There might well be a way to tell ediff to use diff output directly, but that does not guarantee that your 'original' and my 'original' are in any way related. Sending whole files is MUCH more robust.) If it's Windows-specific, try the above list and Andreas Raab. For Mac-specific, the above list and John McIntosh. If it's common code shared by all platforms, especially code generated by VMMaker, send to Dave Lewis and the above list. VM bugs can fed to mantis here: bugs.squeak.org The people mentioned above probably look at mantis on a regular basis. Anything with more than four legs gives me the heebie-jeebies, which isn't why I don't regularly trawl mantis but it'll do. - How a fix in one OS is propagated to the others? Fixes that affect more than one OS are very often in the common code that is generated automatically and shared between all the platforms. There is no explicit manual propagation required. (That being said, the people mentioned above are often in contact on a daily basis. When co-ordination is required, it will happen.) The exception is that some code is shared between Unix and Mac. John is good at spotting commits from me that affect him, and is good at bugging me when necessary into fixing anything Unixy that might affect him. - How the user can know that? Watch vm-dev for discussions or commit reports that say the issue was fixed. If it is in mantis, it might even get closed too. The above reflects how I like to work, and I can only speak for myself. MPG from the others mentioned above might not be comparable. Cheers, Ian (Feel free to forward, re-post, etc., the above as you see fit.) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] new windows (e.g. workspaces) appear wherever they feel like
It seems to flow better if they appeared where the user is already looking i.e. where the active hand is. Issue 2290 : http://code.google.com/p/pharo/issues/detail?id=2290. Sean -- View this message in context: http://n4.nabble.com/new-windows-e-g-workspaces-appear-wherever-they-feel-like-tp1819782p1819782.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] bizarre window cycling behavior
On the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow. Issue 2289: http://code.google.com/p/pharo/issues/detail?id=2289 -- View this message in context: http://n4.nabble.com/bizarre-window-cycling-behavior-tp1819783p1819783.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Communication with VM guys (part three)
Begin forwarded message: From: David T. Lewis le...@mail.msen.com Date: April 9, 2010 2:52:27 PM GMT+02:00 To: Squeak Virtual Machine Development Discussion vm-...@lists.squeakfoundation.org Subject: Re: [Vm-dev] Questions, communication and process Reply-To: Squeak Virtual Machine Development Discussion vm-...@lists.squeakfoundation.org On Fri, Apr 09, 2010 at 11:23:18AM +0200, stephane ducasse wrote: Hi vm guys, I would like to know the process to report problems, issues, enh to the vm because people asked me and I have no idea how this is done. I read the web site but I could not find a bugtracker. Hi Stef, In addition to Ian's explanations, I'll add couple of points. Several questions: - How do people report problems? Just sending an email in the mailing-list is enough? The bugtracker is Mantis at bugs.squeak.org. Use category VM when reporting or searching for problems. For any problems or enhancement requests that may time time to resolve, it is very helpful to use the bugtracker because it provides a process for ensuring that issues are addressed or at least not forgotten, and also a reference for people who run into an issue that someone else has addressed. I try to catch issues that I see on the Pharo and squeak-dev lists and enter them on Mantis if they will need follow up, but I'm sure that I miss things from time to time. Follow Ian's instructions for reporting problems to vm-dev and the platform developer. That is the way that problems get noticed, discussed, and addressed. But to ensure follow-up, please also use the bugtracker. - How a fix in one OS is propagated to the others? - How the user can know that? For issues that affect the VM overall, the change history of the VMMaker package on squeaksource is helpful. You can use Monticello of course, but I like to point a web browser at www.squeaksource.com, project VMMaker, and browse through the entries under the News tab. A remaining problem is that that the VM user cannot always tell if their VM actually contains a particular fix or feature. To some extent you can figure it out from the name of the VM file, but we need a better run time check. We (or I) will probably add a way to check this through a primitive, but for now it remains confusing. Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
I filed bugs for these: Issue 2288: http://code.google.com/p/pharo/issues/detail?id=2288 : Sean P. DeNigris wrote: * what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually… Certainly not a big deal, but weird. I though of a few possible fixes: - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click) Issue 2289: http://code.google.com/p/pharo/issues/detail?id=2289 : Sean P. DeNigris wrote: * bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow. Issue 2290 : http://code.google.com/p/pharo/issues/detail?id=2290 : Sean P. DeNigris wrote: * new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is. Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1819798.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11310
11310 - - Issue 2286: Class definition while compiling method - Issue 2131: Handling Window events. Thanks Henrik - I looked at the code and I would not be able to fix that. again some stuff to learn. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Initial experience coming from Squeak
* what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually… Certainly not a big deal, but weird. I though of a few possible fixes: - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click) Ha, the click-for-focus mosquito finally bit someone besides me. Sean, to live happily ever after, in Preferences, just enable mouseOverForKeyboardFocus. It solves all of the problems you mentioned above, reduces the overall effort needed to use the system because merely pointing at an object endows it with 100+ mouse buttons (left, middle, right, + the whole keyboard). It is more becoming of an object-oriented system, and if you can keep it on long enough to get used to it, I'll bet you'll never want to go back.. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.1] #11310
Me neither, I just looked at the method changed in the .cs Torsten created based on Squeak changes and checked what was appropriate :) Btw, a bad side-effect is you Are no konger able to close a hung image with the close button, since it noe gets sent to the image side for handling. Cheers, Henry Den 9. apr. 2010 kl. 21.54 skrev Stéphane Ducass stephane.duca...@inria.f r: 11310 - - Issue 2286:Class definition while compiling method - Issue 2131:Handling Window events. Thanks Henrik - I looked at the code and I would not be able to fix that. again some stuff to learn. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Canvas transform bug when rendering text?
Not entirely sure sesong as I write this from a phone with no code nearby, but a hunch would be checking the method in question, and try disabling the shadow drawing, Cheers, Henry Den 9. apr. 2010 kl. 23.42 skrev Chris Muller asquea...@gmail.com: Thank you Henrik, it looks like a huge improvement! The attached screen shots help explain why I only said improvement instead of perfect. Look at the color of my translucent morph when it is upright vs. rotated. The translucency is now preserved, which is great! However, do you know why the color seems to lose so much saturation? 2010/4/8 Henrik Sperre Johansen henrik.s.johan...@veloxit.no: On 07.04.2010 14:26, Henrik Johansen wrote: On Apr 7, 2010, at 1:45 49PM, David Harvey wrote: Hi list, I'm writing a little charting morph, and while playing with rotating text for axis labels came across something which I've noted in Morphs text handling a couple of times. If I apply a transform in a drawing operation, rotated text _appears_ to be drawn twice, slightly offset, giving a scrappy bold look. It seems only to do this when drawing on a form canvas that's backed onto the display: if you pick and drag the morph, the text is rendered beautifully. The test morph attached isolates the problem. The transcript logging is an attempt to see what might be happening: looking at the output it appears that there are circumstances in which the during: block is invoked twice. Any thoughts? David http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a1691811 Basically, transform doesn't work with depth 32. Workarounds are described in the thread. Cheers, Henry David, Lukas, whomever else it may concern. Of course I turned out to be (partly) wrong when looking into it. Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating... Try the attached code, and you should get better results. (you probably want to use smoothing 1 if displaying text with rotation other than a multiple of 90 degrees). This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project upright.png rotatedWithFix.png ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes romain.rob...@gmail.comwrote: Dear list, I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. Thanks, this bug was really annoying :) Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest... You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). Cheers, Romain -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain On Apr 9, 2010, at 6:49 PM, Mariano Martinez Peck wrote: On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes romain.rob...@gmail.com wrote: Dear list, I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. Thanks, this bug was really annoying :) Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest... You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). Cheers, Romain -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
On 10.04.2010 01:35, Romain Robbes wrote: Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
On 10.04.2010 01:46, Henrik Sperre Johansen wrote: You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry Err, too many beers... Not much sense in unsubscribing as a result of a window close announcements, the announcer would be gone in a short while anyways :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
Thanks! So that would be for the Pharo 1.1 version, I suppose? Romain On Apr 9, 2010, at 7:46 PM, Henrik Sperre Johansen wrote: On 10.04.2010 01:35, Romain Robbes wrote: Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
I was about to say this. Alexandre On 9 Apr 2010, at 19:46, Henrik Sperre Johansen wrote: On 10.04.2010 01:35, Romain Robbes wrote: Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
Yes, the window announcements are in 1.1 Alexandre On 9 Apr 2010, at 19:51, Romain Robbes wrote: Thanks! So that would be for the Pharo 1.1 version, I suppose? Romain On Apr 9, 2010, at 7:46 PM, Henrik Sperre Johansen wrote: On 10.04.2010 01:35, Romain Robbes wrote: Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
On 10.04.2010 01:51, Romain Robbes wrote: Thanks! So that would be for the Pharo 1.1 version, I suppose? Romain Hopefully, yes :) Personally I find it the most annoying things in rc4 to be: 1 it doesn't close immediately when a) I mouseclick another location in the text (only when I type something) b) change focus to another window 2 It does not update the list location when a) I've mouse-clicked another place in the morph and started typing again. b) I've moved/resized the editor 3) It takes ~ 0.5 -1 second to update if I press down, and on each character typed thereafter with items still in list (Te - down - s - t, s and t take some time to input) 4) Mouse-click on a list item does not select it. 1 is somewhat remedied by the patch I guess, for the rest I guess 2 and 4 should solvable by additional logic, and 3 would require some profiling. 1b and 2a in combination is quite annoying, as the list will be below the morph when you refocus, and in many cases you will be able to see suggestions for the new location. (1/2 b would also be easy to solve with window announcements) In essence, I feel it still could use some improvement with regards to awareness of mouse activity and multiple editors. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] potential bugfix for orphan OCompletion menus
On 10.04.2010 02:21, Alexandre Bergel wrote: Yes, the window announcements are in 1.1 Alexandre Doh, I didn't notice they'd been integrated! :D ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
