- Pharo-dev - lists.pharo.org

Re: [Pharo-project] UI states

by Igor Stasenko

On 20 September 2010 12:50, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Well, that'd be a big overhaul. May as well do something compatible with > CSS3 perhaps? > Yeah this would be a lot of work :) Concerning CSS3, this i thinks is orthogonal, since in CSS you actually describing the style(s) of element (morph in our case), depending on their context and/or state. While i was talking mostly about managing the morph states, not the way how you managing the style information attached to them. > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, September 16, 2010 10:53 PM > Subject: Re: [Pharo-project] UI states > > >> 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. >> >> _______________________________________________ >> 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. 20, 2010

Re: [Pharo-project] HwaJong Oh

by Igor Stasenko

2010/9/20 ë¬ë£ì¤íì¢ <daliot.oh(a)gmail.com>: > Hi, > > i joined this mailinglist. > > I am Korean Hobby Smalltalker first time Europe first time ESUG. > > Hope you remember me. > > - HwaJong - > HwaJong , could you add your name written in latin letters to your email address, because i don't have a Korean font , and i guess many of others too, so your name is shown as a 5 glyph boxes with numbers :) Oh, and please, write something about yourself - the projects you did or doing, because not all of people here was on conference. And if you wanna participate in Pharo development or have some ideas, feel free to put them here or ask questions. > _______________________________________________ > 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. 20, 2010

[Pharo-project] Custom World menu for own apps

by Torsten Bergmann

Just for the records: in Pharo 1.2. it is now possible to define an own custom pragma that is used to define a world menu. This is especially usefull when you create a (commercial) application based on Pharo. How it works: ============= 1. Define your new world context menu by providing class methods with your own custom world menu entries. Instead of using the usual "worldMenu" pragma we use a custom pragma, here "myAppWorldMenu": menuCommandOn: aBuilder <myAppWorldMenu> (aBuilder item: #'About MyApp') action: [ 'HelloWorld' inspect ]; icon: ThemeIcons pharoIcon 2. Switch the world state to use the custom pragram: WorldState desktopMenuTitle: 'My shiny App'. WorldState desktopMenuPragmaKeyword: 'myAppWorldMenu' If you want the old one back just evaluate: WorldState desktopMenuTitle: 'World'. WorldState desktopMenuPragmaKeyword: 'worldMenu' Maybe someone can add this to the open pharo book or give me an account, a short howto and time to include it. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Sept. 20, 2010

[Pharo-project] HwaJong Oh

by ë¬ë£ì¤íì¢

Hi, i joined this mailinglist. I am Korean Hobby Smalltalker first time Europe first time ESUG. Hope you remember me. - HwaJong -

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Guillermo, One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Sunday, September 19, 2010 10:56 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. Guille On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: > Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. > Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class... > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] > Sent: Sunday, September 19, 2010 7:56 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >> hi guys >> >> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >> So we should really have a way to specify silent ui action. >> Does anybody have an idea how I could do that? >> >> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >> > > use morph propertyAt: #borderStyle > so you don't have to break your head with it :) > > BorderedMorph having an enormous number of subclasses, while some of > them even don't using any > kind of borders. That's makes me wonder if anything like color, border > style etc should belong to root classes > in hierarchy, like Morph or BorderedMorph. I think that dynamic set of > properties (which is currently sits in morphic > extensions are more appropriate storage for them). The only problem is > that accessing them is much slower than ivars. > >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] A pattern for GUI programming (Morphic, Cuis, etc)

by Gary Chambers

Well, for the most part they do, aside from the "low-level" #mouseUp etc. Though the "Views" would be idomatically cleaner, they'd also be rather less flexible. Always a trade-off somewhere ;-) As for changing the #changed mechanism, good luck! (massive job). Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, September 19, 2010 10:59 AM Subject: Re: [Pharo-project] A pattern for GUI programming (Morphic, Cuis,etc) > Gary > > what do you think about the main point of juan that View do not raise > event to communicate to their models. > I like that. > > Stef > > On Sep 18, 2010, at 3:23 PM, Juan Vuletich wrote: > >> Hi Folks, >> >> I have developed a GUI programming style, after studying MVC, Morphic, >> MVP and a few others. The model does not know anything about views, there >> are no unneeded redraws, partial updates work correctly, etc. It is >> implemented in the LightWidget hierarchy in Cuis. The documentation I >> wrote is attached. >> >> Cheers, >> Juan Vuletich >> GUI programming with LightWidgets >> ========================== >> >> Warning: Perhaps it is good to read >> AnExampleOfLightWidgetsProgramming.txt prior to reading this... >> >> This document summarizes the way LightWidgets are intended to be used. >> The style for GUI programming is based on PluggableViews in MVC and >> PluggableMorphs in Morphic. The main idea is to have a reusable set of >> standard widgets that can be customized when used. There is a strict >> separation between views and models. Models don't know about views, they >> are never aware of them. Views know about their model and update it >> directly. Therefore views don't trigger events. >> >> This description is not only conceptual, or theoretic. The rules >> described here are to actually be followed. >> >> GUIs are built by composing widgets. The main view is a subclass of >> CompositeLW. There is a complete separation between Model and Views. >> >> Rule 1. Models should never include GUI code >> ---------------------------------------------------------- >> >> They must be completely ignorant of possible Views that operate on them. >> There could be at any time any number of different views active on the >> same model. They could belong to different technologies or frameworks. >> They could even be remote and run on a different computer. There could be >> no view at all. For example, the model could be driven by scripts or >> reside on a server and receive external commands. However, this document >> will only describe local LightWidgets GUIs. >> >> Rule 2. Views should never include any model code >> --------------------------------------------------------------- >> >> The view could be replaced anytime with a different one. Besides, a model >> should be able to run without any GUI at all. So any logic that belongs >> in the model but is included in the GUI will eventually be missing. The >> Views should query and modify Models only through public protocols, >> called 'Inquiries' and 'User Commands'. >> >> Rule 3. Views know about the model they operate on >> ------------------------------------------------------------------- >> >> Views have an instance variable to hold their model. They can query Model >> Inquiries when needed. They can also issue User Commands when >> appropriate. Models are usually subclasses of ActiveModel. Let's consider >> a small example. We are building a GUI to operate on some Person objects. >> We'll consider an EntryField for the birthday of aPerson. LightWidget >> includes the following instance variables: >> >> - target : Holds the Model. For our example, the model of the EntryField >> would be the Person. We call it target, because sometimes it might be a >> view >> - aspect : It is a symbol, the getter for the aspect we are showing. In >> this case it would be #birthday. >> - aspectAdaptor : It is a symbol, a message that is sent to the aspect to >> adapt it to the widget. As the widget is an EntryField and the aspect is >> a Date, the aspectAdaptor could be #asString. This relies the Model from >> the need to provide an appropriate getter for each kind of possible >> widget for each attribute. >> - action : The action is the setter used to update the aspect on the >> model. In this example, it is #birthday:. >> - actionAdaptor : It is used to adapt the value the user entered in the >> widget for use as an argument of action. In this example it could be >> #asDate. >> It is usually a good idea to initialize model aspects with reasonable >> defaults, and avoid nil values. This saves a lot of #ifNil: messages in >> the gui. >> >> Rule 4. View Structure >> ---------------------------- >> >> A Model could have a tree-like structure. It could be composed of other >> Models. This is not mandatory. >> Views always have a tree-like structure. The leaves are simple widgets. >> The internal nodes are CompositeLWs. They can all share the same model, >> or they could could use different parts of the bigger model. Anyway, they >> are customized with the aspec and action. >> >> Rule 5. GUI construction >> ------------------------------ >> >> The construction of the Views tree and the customization of each widget >> is done by a main view. The main view also specifies how the Views are >> notified of model changes for updating. >> >> Rule 6. Instance variables in views >> -------------------------------------------- >> >> Additional instance variables in GUIs are of two kinds: They can be uses >> to hold sub-views, or to hold 'Model Extensions'. Possible uses of Model >> Extensions include: >> - Holding information that can be obtained from the aspect, but that >> could be expensive and it makes sense to cache. For example, our >> EntryField could hold an array if indices of word starts and ends or some >> other internal detail. >> - Holding state that is meaningful for the widget, but that it doesn't >> make any sense to keep in the model. An example could be the cursor >> position in our EntryField. Others could be visual options, such as a >> graph type or graph style for an application generated graph. >> - Not-yet-commited information, entered by the user, but awaiting for OK >> / Cancel. >> In general, Model Extensions usually are re-fetched from the model, or >> re-set to default values when the model changes. >> >> Rule 7. View updating because of model changes >> --------------------------------------------------------- >> >> Any widget (in fact, any Morph) can redraw itself when needed, with the >> #changed method. But when there is a change in the Model, the views must >> be updated appropriately. All the Model Extensions must be updated, and >> all sub-views must be updated too. >> >> When there is a change in the Model, the Views must receive the >> #modelChanged message. A main view (i.e. a view that is not subview of >> another view with the same Model) must send itself #beMainViewOn: on >> construction. This does 'target when: #selfChanged send: >> #safeModelChanged to: self'. The Model must trigger event #selfChanged >> when appropriate. #safeModelChanged will eventually update all subviews >> recursively. So only a main view should receive the #selfChanged event. >> Models are usually subclasses of ActiveModel, to use the more advanced >> events implementation there. >> >> This is the implementation of #beMainViewOn: . This message should be >> used to set the model of a main view. >> >> beMainViewOn: aModel >> "We are a main view on aModel. >> This means: >> - aModel is a real model, i.e. not a widget. >> - no aspect or aspectAdaptor. We show the whole thing. >> - no action or actionAdaptor. There is no main action. >> - we must update ourselves on #selfChanged event" >> >> self target: aModel aspect: nil aspectAdaptor: nil modelChangeEvent: >> #selfChanged >> >> The main update method is #modelChanged. #safeModelChanged is only to >> guarantee that the update is done in the User Interface process, in the >> inter-cycle paus. The implementation of #modelChanged at LightWidget is: >> >> modelChanged >> "The model changed is some way. >> This is usually the pace to call #targetAspect to fetch the current value >> of the aspect from the >> model, and to store it in some Model Extension. >> We must update all Model Extension instance variables with values from >> the model (i.e. target) >> or with appropriate defaults. >> We must update ourselves and all subviews to reflect the model's new >> state" >> >> self updateView >> >> #modelChanged must be reimplemented in classes with model extensions. >> Check the implementors to see how they work. >> >> After updating the model and model extensions, #updateView is called. >> This is the implementation at LightWidget: >> >> updateView >> "The model or some Model Extension changed is some way. >> We must update ourselves to reflect the new state. >> >> This is the place to update secondary Model Extensions or any other state >> that must be updated >> after model or Model Extension change. >> >> This method is usually reimplemented in CompositeLWs, to update subviews. >> >> The subviews should be sent one of the following messages: >> target: >> target:aspect: >> target:aspect:aspectAdaptor: >> target:aspect:aspectAdaptor:aspectChangeEvent: >> to update their model and do a full update, as triggered by >> #modelChanged" >> >> self changed >> >> Warning: Never implement other methods like #updateViews. If for >> performance reasons the updating of subviews must be splitted in parts, >> then the views and subviews must be restructured accordingly. Then, each >> part can be updated as a whole with the #updateView method. Each part can >> be updated by more specific model change events, or alternatively, they >> might be set different submodels. Both options are described below. >> >> The update of widgets should never trigger the action of the widget. >> >> Rule 8. View updating because of Model Extension changes >> ------------------------------------------------------------------------ >> >> If the target of a widget is another widget, the action is a User Command >> on the target widget. These methods should not update the model, because >> if this was the case, the target should be the model and not the widget. >> Therefore, User Command methods in widgets can only update Model >> Extensions or trigger view actions, such as opening new views, etc. If >> they update Model Extensions they should call #updateView, so the change >> is shown in the widget and its subviews. >> >> sampleUserCommand: data >> modelExtension1 := data. >> self updateView >> "Must call updateView because the model didn't change, and it will not >> trigger any change event" >> >> Rule 9. Subview updating because of submodel changes >> -------------------------------------------------------------------- >> >> If the model has a tree-like structure, its view will send #beMainViewOn: >> aSubModel to some subviews with a part of the model as the argument. In >> this case, subviews will need to be notified of the events of their own >> models. This is because the submodel might trigger the #selfChanged >> event, and only the views on it should be updated. Views on the bigger >> model don't need to be updated. This is good for performance when having >> complex models and views. >> >> Rule 10. Subview updating because of model minor changes >> ----------------------------------------------------------------------- >> >> There is another reason for subviews receiving event notifications. A >> model could trigger a more specific #someAspectChanged event and NOT the >> main #selfChanged event. This could be done to avoid superfluous and >> extensive views updating. In this case, some specific view on the view >> tree should receive the #updateView message, and only the widgets that >> are part of it will be updated. >> >> So, the owing view should send >> #target:aspect:aspectAdaptor:modelChangeEvent: to these subviews. The >> implementation is: >> >> target: aModel aspect: aSymbol aspectAdaptor: anotherSymbol >> modelChangeEvent: eventSymbol >> "Widgets are notified of model changes by being sent #modelChanged. >> This happens when: >> - The widget is given a new model (or target widget), aspect or aspect >> adaptor >> - An owner view is updated >> >> In addition, main views are updated from model events. See #beMainViewOn: >> >> But other widgets might update on more specific events from the model. >> This is useful to >> update only a small subview, and not the whole main view. >> >> This message is sent to such widgets, to set this specific event. >> >> Warning: >> When models change, they should trigger just one event. >> It might be #selfChanged (the most general one) or a more specific one. >> But it should not trigger more than one event for each change." >> >> self target: aModel aspect: aSymbol aspectAdaptor: anotherSymbol. >> target when: eventSymbol send: #safeModelChanged to: self >> >> Warning: When a model triggers more specific change events we must make >> sure some widget will be notified of them. Otherwise, those changes could >> not be shown to the user. >> >> Pensar un cacho en como actualizar estas cuando ocurra la actualizacion >> general. Creo que es justo cuando hay que decirle target:... SI! >> >> Rule 11. Accessing views >> ------------------------------ >> >> Nobody should ever query a widget for value or status. A widget should >> not even query itself for current value or such. The last value or state >> entered by the user should be stored in the model and/or Model >> Extensions. When needed, it should be retrieved from there. The only >> legitimate accesses to subviews are in #initialize and in #updateView. >> Check implementors of #updateView. >> >> Rule 12. Model updating >> --------------------------- >> >> Views DO NOT trigger events. This is not "Event Oriented Programming". >> This is Object Oriented Programming. The model is updated using the >> action and the optative actionAdaptor. Methods that react to user >> activity should update the model by just using the action, a simple >> message. They are not allowed to ask the model for some other object to >> work on it. They are not allowed to send other messages to the model. >> They are allowed to modify Model Extensions. If they do, theyshould also >> call sned 'self modelChanged' because an action might not modify the >> model and therefore there could not be a model change event. See >> ButtonLW>>mouseUp: for an example of this. >> >> If you ever feel the need to update the object answered by the aspec, >> instead of sending a new value to the model (ivar target), it is because >> that aspect should be the real model. >> >> Rule 13. GUI building >> ------------------------ >> >> Main views know about their subviews. Therefore it's them, in theire >> #initialize method, who build the subviews and customizes them. Views are >> created before assigning target or model to the main view. Afterwards, >> the model or target is set, and #modelChanged is called. As seen before, >> this will set the model or target of all subviews recursively. >> >> >> Misc. notes >> ------------------- >> >> I believe nobody should do #modelChanged, but only #safeModelChanged. >> Think a bit about this. Maybe if we're certain we're in the UI process, >> #modelChanged is ok... >> >> If a visual detail like #fontColor: in a LabelLW is updated, after >> updating the ivar, the widget should do 'self changed'. Check the code to >> see that it is actually done!An example of LightWidgets programming >> =========================== >> >> The ProgrammingWithLightWidgets.txt document might be a little boring to >> read with all those rules. This document, instead, shows the style of >> LightWidgets programming based on a concrete example. It focuses on >> building application guis, an not on building widgets themselves. GUIs >> done following the LightWidgets ideas are very simple. Remembering the >> rules might seem a bit rigid, but this avoids complexity in the GUI, >> making long term mainteinance easier. >> >> The example I chose is the Local Users screen in Squeak STB, class >> STBLocalUserEditorLW. Model are instances of STBLocalUser. >> >> Note that even though models are advised to inherit from ActiveModel, >> STBLocalUser does not. This shows a general rule: Views don't have the >> right to say how models should work. Models are independent of views. In >> this case, STBLocalUser inherits from STBModel, the class of persistent >> objects in the box. >> >> Local users are pretty simple objects. They have a userName, a password >> (only a passwordHash is stored), and a list of groups the user belongs >> to. >> >> The GUI has the following widgets: >> - An entry field for the name >> - An entry field for the password >> - A list of groups the user belongs to. Selecting one and doing <ok> >> removes the group from the user >> - A list of available groups (groups the user does not belong to). >> Selecting one and doing <ok> adds the group to the user. >> >> In addition, we have: >> - A 'Create new User' button >> - A list of existing users. Selecting one and doing <ok> edits that user >> - A 'Save' button >> - A 'Close' button that exist without saving >> - A 'Delete' button used to actually delete the currently edited user >> >> Class STBLocalUserEditorLW has several instance variables for holding its >> widgets, one model extension 'password'. and one visual property: >> 'backColor'. Instance variable 'backColor' is only there to avoid >> computing it each time thescreen is redrawn. Instance variable 'password' >> is needed because the STBLocalUser can not answer it. >> >> The model is an instance of STBLocalUser. However, the list of available >> users does not depend on it. This list has content even if no model is >> assigned yet. The model is set later, in messages #selectedUser: and >> #newUser. >> >> Initialization >> ----------------- >> >> Method #initialize creates all the widgets. It is quite long but it does >> not do anything interesting. It just creates the widgets, lays them out, >> adds them as submorphs, and stores them in instance variables. It also >> does 'self newUser', so the user does not need to click the button before >> entering data. >> >> Note that the target of all buttons is 'self', meaning that user commands >> will be processed by the editor itself. In many cases, (as in the name >> fields in this editor) the target of the actions would be the model >> instead. >> >> drawing >> ------------ >> >> Method #drawOn: is there only because the backColor is defined in this >> class. >> >> updating >> ------------ >> >> #updateView - This method is called after a new model is set, or if model >> changes. It sets labels to appropriate values, updates the current and >> available group lists, and sets the STBUser as the target of the name >> field. In addition it updates the users list. >> >> #password - helper method to access the password entered by the user. >> >> user commands >> ----------------------- >> >> #newUser - Creates a new user and sets it as the model of the view. >> >> #selectedUser: - Sets the selected user as the model of the view. >> (Persistent objects note: Persistence is paused, to be resumed in case of >> save. If the user cancels, nothing should be persisted!) >> >> #password: - This is processed here (and not just in the model) to store >> the password entered by the user. >> >> #addGroup: - This is processed here (and not just in the model) to >> handle keyboard focus. >> >> #removeGroup: - This is processed here (and not just in the model) to >> handle keyboard focus. >> >> #saveUser - This makes changes persistent, and logs stuff. >> >> #deleteUser - This removes the user from the persistent pool and logs >> stuff. >> >> #cancel - This undoes any changes (by going back to the persisted state), >> resumes persistence, and closes the editor >> >> That's all. It wasn't hard at all, was >> it?_______________________________________________ >> 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. 20, 2010

Re: [Pharo-project] VM Plugins internal vs external

by Alexander LazareviÄ

Hi Noury! Well the internal plugins are part of the vm executable and the external plugins are shipped as separate shared library files. The interface to both variants is the same, but not every vm plugin might work as an external or internal plugin depending on the implementation. I don't know if this is still true, but there was also the idea, that an external plugin "overrides" an internal version. So in the case of a malfunctioning internal plugin, you could ship a new external plugin of the same name that will be used instead of the internal one when placed in a location of the vm plugin paths. But that's all out of my flaky memory and could be totally different nowadays.:) Alex 2010/9/20 Noury Bouraqadi <bouraqadi(a)gmail.com>: > Hi, > > What is the difference between internal and external plugins in the VM? > > Noury > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] MethodName is now Finder

by Gary Chambers

Very nice! Regards, Gary ----- Original Message ----- From: Benjamin Van Ryseghem To: pharo-project(a)lists.gforge.inria.fr Sent: Saturday, September 18, 2010 5:45 PM Subject: [Pharo-project] MethodName is now Finder Hello everyone ^^ After a week in ESUG and thanks to Alain and Tobias, I've improved the Finder tool :) To test it, you have to download : Gofer new squeaksource: 'PharoTaskForces'; package: 'NullTextStyler'; load Gofer new squeaksource: 'PharoTaskForces'; package: 'DialogItemsChooser'; load and the last but not the least : Gofer new squeaksource: 'PharoTaskForces'; package: 'Finder'; load It works only on Pharo 1.2 and you will probably have an error due to an issue about PluggableTextMorph : http://code.google.com/p/pharo/issues/detail?id=2973 To open it, just click World >> Tools >> Finder Ben ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

[Pharo-project] VM Plugins internal vs external

by Torsten Bergmann

>From what i know, it has more to do with having smaller sized vm's, than >with efficiency reasons. Yes, and with security. Thats why FFI is external. If you remove it all code (downloaded or not) can only use built in primitives and its not possible to call OS API's and harm your computer. Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Sept. 20, 2010

Re: [Pharo-project] UI states

by Gary Chambers

Well, that'd be a big overhaul. May as well do something compatible with CSS3 perhaps? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 10:53 PM Subject: Re: [Pharo-project] UI states > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010