- Pharo-dev - lists.pharo.org

[Pharo-project] ISSUE 2967: urgent do-it fix

by Fernando olivero

Issue 2967: DoIt on a workspace doesnt work, raises a subscript out of bounds error. Fixed, removed some other methods that were added to ByteString, but belong in SmalltalkEditor. Fernando

Sept. 16, 2010

Re: [Pharo-project] UI states

by Igor Stasenko

2010/9/16 Gary Chambers <gazzaguru2(a)btinternet.com>: > IÂ might be niceÂ for the appearance of all controls, windows etc. to adhere > to a standard set of UI states as identified: > > Enabled > Enabled Mouse over > Enabled Mouse down inside > Enabled Mouse down outside (*) > > Enabled Selected > Enabled Selected Mouse over > Enabled Selected Mouse down inside > Enabled Selected Mouse down outside (*) > > Disabled > Disabled Mouse over (*) > Disabled Mouse down inside (*) > Disabled Mouse down outside (*) > > Disabled Selected > Disabled SelectedÂ Mouse over (*) > Disabled Selected Mouse down inside (*) > Disabled Selected Mouse down outside (*) > > And repeat for additional "inactive" (non-primary/top window) > > > (*) indicates a nice to have, rather than strictly necessary... > > Thoughts appreciated beforehand. Anything missing, suggestions for fallback > (don't want to have to do all for everything)?... > > Perhpas worth a tutorial/help/etc. for those making new widgets. > > > I'm sure I discussed this with Igor before, but not sure I had a response. > We discussed a lot before, so i am also not sure if we touched this topic before :) My own (1 year old) idea about states is different. In short: a widget state is better to describe not by a set of flags (disabled/enabled, mouse over/out etc etc), but with stack of modes, where topmost mode (on stack) having a greater preference above those which follow. Then you can easily control the widget appearance depending on modes. An example. By default, you rendering a button using blue color. When mouse is over it, you render it with light-blue color. When button is disabled, you render it with gray color, regardless if mouse over or not over it. >From the above description, its easy to compose a right stack of modes, which affecting the widget appearance: initially, a stack is empty( we assume default mode on stack) - default mode (blue background) when mouse enters a widget, you simply pushing a new mode on widget's mode stack: - mouse over(light-blue) - default mode (blue background) and when it leaves, in response to such event, you simply removing the corresponding mode from stack: - default mode (blue background) But one things with disabled dome, that you want a 'disabled mode' to be always on top of the mode stack, regardless of any other modes, which means that you likely don't wanna have: - mouse over(light-blue) - disabled(gray) - default mode (blue background) but always want - disabled(gray) - mouse over(light-blue) ... - default mode (blue background) so, a color, attached to it is always takes a preference. To deal with this, we need just one more rule: each mode having a priority , or (weight), and a simple rule, that when you pushing a mode with lower priority than currently on top of the stack, you insert it after the mode of highest priority you met, so then, when you have it like following: - disabled(100) - default (0) and mouse enters the widget, you making a 'mouseover' mode to have >0 but < 100 priority value, so it is always pushed after disabled. - disabled(100) - mouseover(1) - default (0) in addition to that, in my experimental project, i can attach any attribute to mode(s), so it is more like a set of css rules (a:hover, a:link ...) , so i can even say that in disabled mode i don't even want to react on a mouse enter/leave events so i don't need to be bothered by using priorities, because mouseover mode is never get pushed on mode stack. The next thing, what i'd like to tell more about modes and styles: to render a widget, i start looking for some property (like background color) along the mode stack. And if topmost mode does not defining it, then i going down the stack and querying this property for next mode. Then finally, if its defined nowhere, it goes down to default mode, where it should answer a default value. In this way i have a quite flexible way to define a styles. I can change a various properties for one mode, but leave the rest untouched. More on top of that, i am even can modify a property value(s), returned by mode with sits down the stack.. but i think this is too much for this mail. I just wanted to show you how much more flexibility you can get by using this model :) > Regards, Gary > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 16, 2010

Re: [Pharo-project] Some thoughts...

by Igor Stasenko

Amen :) On 15 September 2010 12:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > nativeBoost too :) > > Stef > > On Sep 15, 2010, at 11:08 AM, Tudor Girba wrote: > >> Indeed, this sounds really exciting. >> >> Doru >> >> >> On 14 Sep 2010, at 17:59, StÃ©phane Ducasse wrote: >> >>> thanks alex :) >>> We will.... >>> >>> Stef >>> >>>> Hi, >>>> >>>> I really would like to see projects like Opal and Ocean happening. Even though I may not have the time to directly contribute to them, they are important and I will use them. I am struggling these days to instrument the whole Pharo image and this is not easy. I am eagerly waiting for Opal. I got burned in the past with networks. >>>> >>>> So, please continue... >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel Â http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 16, 2010

Re: [Pharo-project] UI states

by Gary Chambers

Would be nice to separate the concept/functionality of controls from appearance/feel too... seems a bit like player/costume from EToys but more focussed. Possible to do via Theme I think. Some refactoring required though (lol). Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 6:59 PM Subject: Re: [Pharo-project] UI states > Native would have these state (mostly). > I think the "toolbox" set should support this (mostly there at the > moment). > In terms of Morphic this is mirrored *and* orthogonal to native stuff... > I think what I proposed is pretty much the superset accross native > platforms. Supporting that would, hopefully, reduce the "least common > denominator" problem with respect to native controls. > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, September 16, 2010 6:34 PM > Subject: Re: [Pharo-project] UI states > > >> Gary, >> >> Questions more than thoughts :) Are the Mouse*Outside states for mouse >> capture? Otherwise, would there not be another owner? Just checking. >> Are these symbols, or are you thinkng of reifying them so they can >> provide behavior? >> >> If you are planning a major revision, please telegraph that (or consider >> this a warning to keep it a secret<g>) so we can discuss questions of MVP >> or similar design considerations. >> >> At some point, I begin to wonder whether we should just go native via wx >> or a similar framework. The good part about it for the Squeak in Pharo >> would be to force discipline of an event queue, input focus, modality >> when it applies, hopefully put an end to polling, etc. I am not a >> knee-jerk believer in "native is faster." In fact, I ended up emulating >> widgets in Dolphin specifically to get speed! Perhaps one has to go to >> very large number of sub-widgets for that to matter, but it does >> eventually arise. Even with that concern, I think we would be better off >> using one native window per tool; whether or not each pane and control >> should be native is up to interpretation. Not doing it because we >> haven't is not a great idea, nor is doing whether or not we should. >> Comments? >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers >> [gazzaguru2(a)btinternet.com] >> Sent: Thursday, September 16, 2010 1:13 PM >> To: Pharo Development >> Subject: [Pharo-project] UI states >> >> I might be nice for the appearance of all controls, windows etc. to >> adhere to a standard set of UI states as identified: >> >> Enabled >> Enabled Mouse over >> Enabled Mouse down inside >> Enabled Mouse down outside (*) >> >> Enabled Selected >> Enabled Selected Mouse over >> Enabled Selected Mouse down inside >> Enabled Selected Mouse down outside (*) >> >> Disabled >> Disabled Mouse over (*) >> Disabled Mouse down inside (*) >> Disabled Mouse down outside (*) >> >> Disabled Selected >> Disabled Selected Mouse over (*) >> Disabled Selected Mouse down inside (*) >> Disabled Selected Mouse down outside (*) >> >> And repeat for additional "inactive" (non-primary/top window) >> >> >> (*) indicates a nice to have, rather than strictly necessary... >> >> Thoughts appreciated beforehand. Anything missing, suggestions for >> fallback (don't want to have to do all for everything)?... >> >> Perhpas worth a tutorial/help/etc. for those making new widgets. >> >> >> I'm sure I discussed this with Igor before, but not sure I had a >> response. >> >> Regards, Gary >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2010

Re: [Pharo-project] UI states

by Gary Chambers

Native would have these state (mostly). I think the "toolbox" set should support this (mostly there at the moment). In terms of Morphic this is mirrored *and* orthogonal to native stuff... I think what I proposed is pretty much the superset accross native platforms. Supporting that would, hopefully, reduce the "least common denominator" problem with respect to native controls. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 6:34 PM Subject: Re: [Pharo-project] UI states > Gary, > > Questions more than thoughts :) Are the Mouse*Outside states for mouse > capture? Otherwise, would there not be another owner? Just checking. > Are these symbols, or are you thinkng of reifying them so they can provide > behavior? > > If you are planning a major revision, please telegraph that (or consider > this a warning to keep it a secret<g>) so we can discuss questions of MVP > or similar design considerations. > > At some point, I begin to wonder whether we should just go native via wx > or a similar framework. The good part about it for the Squeak in Pharo > would be to force discipline of an event queue, input focus, modality when > it applies, hopefully put an end to polling, etc. I am not a knee-jerk > believer in "native is faster." In fact, I ended up emulating widgets in > Dolphin specifically to get speed! Perhaps one has to go to very large > number of sub-widgets for that to matter, but it does eventually arise. > Even with that concern, I think we would be better off using one native > window per tool; whether or not each pane and control should be native is > up to interpretation. Not doing it because we haven't is not a great > idea, nor is doing whether or not we should. Comments? > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers > [gazzaguru2(a)btinternet.com] > Sent: Thursday, September 16, 2010 1:13 PM > To: Pharo Development > Subject: [Pharo-project] UI states > > I might be nice for the appearance of all controls, windows etc. to adhere > to a standard set of UI states as identified: > > Enabled > Enabled Mouse over > Enabled Mouse down inside > Enabled Mouse down outside (*) > > Enabled Selected > Enabled Selected Mouse over > Enabled Selected Mouse down inside > Enabled Selected Mouse down outside (*) > > Disabled > Disabled Mouse over (*) > Disabled Mouse down inside (*) > Disabled Mouse down outside (*) > > Disabled Selected > Disabled Selected Mouse over (*) > Disabled Selected Mouse down inside (*) > Disabled Selected Mouse down outside (*) > > And repeat for additional "inactive" (non-primary/top window) > > > (*) indicates a nice to have, rather than strictly necessary... > > Thoughts appreciated beforehand. Anything missing, suggestions for > fallback (don't want to have to do all for everything)?... > > Perhpas worth a tutorial/help/etc. for those making new widgets. > > > I'm sure I discussed this with Igor before, but not sure I had a response. > > Regards, Gary > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2010

Re: [Pharo-project] UI states

by Schwab,Wilhelm K

Gary, Questions more than thoughts :) Are the Mouse*Outside states for mouse capture? Otherwise, would there not be another owner? Just checking. Are these symbols, or are you thinkng of reifying them so they can provide behavior? If you are planning a major revision, please telegraph that (or consider this a warning to keep it a secret<g>) so we can discuss questions of MVP or similar design considerations. At some point, I begin to wonder whether we should just go native via wx or a similar framework. The good part about it for the Squeak in Pharo would be to force discipline of an event queue, input focus, modality when it applies, hopefully put an end to polling, etc. I am not a knee-jerk believer in "native is faster." In fact, I ended up emulating widgets in Dolphin specifically to get speed! Perhaps one has to go to very large number of sub-widgets for that to matter, but it does eventually arise. Even with that concern, I think we would be better off using one native window per tool; whether or not each pane and control should be native is up to interpretation. Not doing it because we haven't is not a great idea, nor is doing whether or not we should. Comments? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] Sent: Thursday, September 16, 2010 1:13 PM To: Pharo Development Subject: [Pharo-project] UI states I might be nice for the appearance of all controls, windows etc. to adhere to a standard set of UI states as identified: Enabled Enabled Mouse over Enabled Mouse down inside Enabled Mouse down outside (*) Enabled Selected Enabled Selected Mouse over Enabled Selected Mouse down inside Enabled Selected Mouse down outside (*) Disabled Disabled Mouse over (*) Disabled Mouse down inside (*) Disabled Mouse down outside (*) Disabled Selected Disabled Selected Mouse over (*) Disabled Selected Mouse down inside (*) Disabled Selected Mouse down outside (*) And repeat for additional "inactive" (non-primary/top window) (*) indicates a nice to have, rather than strictly necessary... Thoughts appreciated beforehand. Anything missing, suggestions for fallback (don't want to have to do all for everything)?... Perhpas worth a tutorial/help/etc. for those making new widgets. I'm sure I discussed this with Igor before, but not sure I had a response. Regards, Gary

Sept. 16, 2010

[Pharo-project] UI states

by Gary Chambers

I might be nice for the appearance of all controls, windows etc. to adhere to a standard set of UI states as identified: Enabled Enabled Mouse over Enabled Mouse down inside Enabled Mouse down outside (*) Enabled Selected Enabled Selected Mouse over Enabled Selected Mouse down inside Enabled Selected Mouse down outside (*) Disabled Disabled Mouse over (*) Disabled Mouse down inside (*) Disabled Mouse down outside (*) Disabled Selected Disabled Selected Mouse over (*) Disabled Selected Mouse down inside (*) Disabled Selected Mouse down outside (*) And repeat for additional "inactive" (non-primary/top window) (*) indicates a nice to have, rather than strictly necessary... Thoughts appreciated beforehand. Anything missing, suggestions for fallback (don't want to have to do all for everything)?... Perhpas worth a tutorial/help/etc. for those making new widgets. I'm sure I discussed this with Igor before, but not sure I had a response. Regards, Gary

Sept. 16, 2010

Re: [Pharo-project] Best Spreading Smalltalk Actions

by laurent laffont

Thank you !! Laurent On Thu, Sep 16, 2010 at 4:27 PM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote: > Although the technology is important, spreading the word is also of great > value to the Smalltalk community. > This is why the ESUG board decided to distinguish two people for their > actions on this-level: > > -Damien Cassou > for Squeak-dev: an initiative which makes developers life easier by setting > a ready to use image including best available tools. > > -Laurent Laffont > for Pharocast: quality screencasts that illustrates various facets of > http://pharocasts.blogspot.com/ > > Congratulations Damien and Laurent! > > Noury @ ESUG 2010 - Barcelona :-) > --- > 18th International Smalltalk Joint Conference, September 13 -17 2010 > Barcelona, Spain. > http://www.esug.org/Conferences/2010 > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2010

[Pharo-project] Looking for a C parser

by Luc Fabresse

Hi all, I'm looking for a C parser (header files would be enough) to get an AST. I found the "CAnalyzer" project on squeaksource but tests are not green and it seems to be tight with an XML generator. Is there another projectt? something on the top of PetitParser? Thanks, #Luc

Sept. 16, 2010

[Pharo-project] Best Spreading Smalltalk Actions

by Noury Bouraqadi

Although the technology is important, spreading the word is also of great value to the Smalltalk community. This is why the ESUG board decided to distinguish two people for their actions on this-level: -Damien Cassou for Squeak-dev: an initiative which makes developers life easier by setting a ready to use image including best available tools. -Laurent Laffont for Pharocast: quality screencasts that illustrates various facets of http://pharocasts.blogspot.com/ Congratulations Damien and Laurent! Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010

Sept. 16, 2010