UI August 2007

ui@lists.squeakfoundation.org

17 participants
27 discussions

Widgets ready
by Gary Chambers 29 Aug '07

29 Aug '07

Well, I think the Widgets/UITheme stuff is ready for a first release :-) Tested on a stock 3.9 image, not looked at 3.10 yet... Consists of two Monticello packages: The main "Widgets" package including theme support and Morphic fixes; An extra ToolBuilder package to integrate the new dialogs into the environment (where UIManager is used at any rate, directly or indirectly). Looks nicer with Andy Tween's FreeType packages installed though will work without. Any suggestions as to how people want the packages submitted? My SqueakMap account sadly points to an older email and I've forgotten the password... If people would like a script for setting preferences I can post here. Will repost this on squeak-dev for those not following here! Gary.

1 0

Re: [UI] State of morphic ... etc,
by Bill Schwab 29 Aug '07

29 Aug '07

Sig, Agreed, the gratuitous "you can always keep your changes in your image" is better left unsaid. Or is it? Some days I think that is precisely what needs to happen: a group of people could form with the goal of cooperating to build a new Squeak with a reasonably modern GUI, as much ANSI compatibility as they can manage, a clean compiler, clean collections and streams, and ideally with version control that is more formal than anarchy, but provides a way for work like Zurgle, Gary's efforts, and a foundation like you are trying to create to actually become adopted. Pavel's kernel work might be a big help. New versions would be synthesized by assembling packages. Gary seems to have mastered the art of debugging the user interface, which would enable the kinds of changes you want to make. If he has not already done so, hopefully there are some abstractions that would help others move existing code to a clean framework. I have a few thoughts on graphics. Like you, I care about other devices (printers) and have adapted my coding to greatly cut down on the ugliness of debugging graphics, but not at the level that Gary must be working. Releases could be planned by functionality to be included, in the following sense: to protect all interests, there should be a way to tell people with really weird ideas to "go away," but the focus should be on turning ideas into benign hooks to allow new packages to install and work or fail on their own merits. Where possible, anything that is included should have tests. Hooks might need to be reviewed after some time passes to see whether they have gone unused, and sun setted if they are simply taking up space. OTOH, if they are packages that never get installed, they would be self-cleaning. I suggest formalizing hooks up front to easy adoption in the new package's future. As much as I hate to talk about creating yet another fork of Squeak, I think the time has come for a bunch of like-minded people to "keep changes in their own image." We would simply be doing what the community suggests ;) Bill ========================== Igor Stasenko siguctua at gmail.com Tue Aug 28 14:09:28 UTC 2007: Well, i agree that problems must be described precisely and also possible ways how to solve them. But i doubt that someone except me (or others who look forward to support GL rendering) will support the changes. A most 'killer' arguments always be: it works fine now, why do we need to change anything? And then: you can keep your changes in your image. And such position doesn't helps with moving forward for the benefit of all. You can reread my early notes on all of this. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-April/115907.ht… I described most of my problems there :) Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

UI (was RE: A couple of simple ergonomic adjustments onsqueak-dev)
by Bill Schwab 28 Aug '07

28 Aug '07

Hello all, Sorry, I was a little slow to notice the discussion moved - thanks for getting this going! Gary, I am also eager to try your changes. Themes, tabbing, dialog framework, more widgets - if it is at all what I am imagining, Squeak has needed this for a long time. I think I follow you on "for end-user deployment the package can be loaded then if you prefer the standard development environment." I will very likely load the changes and never look back, but I am concerned about synchronizing with future changes to Squeak. I hope that we can get your work folded into the mainstream, or is the plan to lead by example? Another way to say that would be, do you plan to ultimately fork Squeak, or will you continue to adapt to each release? Clearly you recognize the larger community might have reservations about the feel changes. Are your feel changes themed or otherwise pluggable? Could they be made so? That might give us a better chance of reaching wide acceptance. Failing that, Pavel's work might provide an opportunity to build a clean system from the ground up, which might be even better?? Thanks!! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

2 1

State of morphic ... etc,
by Jerome Peace 28 Aug '07

28 Aug '07

State of morphic Hi Sig, I look forward to seeing your enhancements. The best way to address these issues is to raise a flag for each of them in the form of a mantis report. Keep separate ideas separate and possibly also create a mother report for collecting similar ideas together under one banner. The challange with putting complaints on mantis is 1) to describe each problem clearly. I usually give a simple recipe for running into trouble. And then 2 ) to add to the report as you gather more information or code to support your view of things. No one here is tasked with solving other peoples problems (or good ideas) for free. If you are the first one bugged about something. You are probably also the first one who will do something about it. No matter how long it takes. Mantis provides the possibilty others will notice and support an issue. And it provides patience and persistance to get the fixes in front of the release teams. Here are the Faqs: FAQ: Is this a known issue ? Where is the place to report bugs (or check if some have already been raised) ? The best place for this info would be to start a Mantis report. (You can get a mantis acct freely and easily). A good place to start is: http://bugs.squeak.org/my_view_page.php Mantis provides a patient persistent way to focus on an issue. I use it to accumulate data on a problem until a solution can be found. It provides a place to alert the community to a problem; -accumulate facts and clues from the analysis; -publish preposed solutions and get feedback; -get solutions harvested and included into the main stream. This FAQ is available at the Squeak wiki site. http://wiki.squeak.org/squeak/Mantis%20FAQ%20and%20Tips aka: http://wiki.squeak.org/squeak/5912 Mantis FAQ and Tips *** >Igor Stasenko siguctua at gmail.com >Mon Aug 27 15:40:49 UTC 2007 > > >Jerome, thank you for good overview. >My personal interest, as you may know, is the graphics part of morphic. >I'm developer of GLMorphic project, which draws all morphs using openGL. > >There are some things which i wish to be cleaned up / rethought. >First is the hard-wiring with Forms and blitting: i don't like, that >many morphs relying on fact, that display surface represented by >rectangular area of pixels (Forms), and can be manipulated directly >with blitting operations. >This is what i want to be avoided at all, and to draw all morphs using >calls to canvas only. > >Second is font rendering and paragraphs rendering. Most of morphs use >paragraphs to hold text, and paragraphs using special class like >CanvasCharacterScanner which containing very complex and ugly (IMHO) >code to render text. I don't know why simple text rendering became so >complex in respect to rendering paragraphs. And i wish this to be >simplified someday. >Personally i don't think that message #paragraph:bounds:color: need to >be included in Canvas protocol, since its too complex to pass in >single command and always splitting to more basic commands like draw >string. > > >-- >Best regards, >Igor Stasenko AKA sig. *** ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/

2 1

Re: [UI] Squeak UI guidelines/heuristics
by Bill Schwab 28 Aug '07

28 Aug '07

Jason, I have a pretty good understanding of Dolphin's MVP framework. Views are created from serialized prototype instances. Composite views are quite natural - just start with a shell or a container view and sub-views, assign layout managers, etc. New views can be wrapped, though I haven't needed to do it in a long time. IIRC, it involves sending something like #addView:asResource: to the appropriate presenter. It might also be possible to trick the VC into doing it, though it is pretty rare, largely being a task for the creator of a wrapper for a widget library - after that, it's done. The _real_ problems are in maintaining serialization (STB) conversion methods in View subclasses. That is "easy" (well, very doable) in classes owned by one entity, but when two vendors have different release cycles, it can get messy. OA made some changes to help with it, but I remain slightly skeptical, perhaps only because the one or two custom views I have got started before that change. IMHO, there is very little reason to make new views in Dolphin, and I wish I had understood that from the beginning. If I ever have trouble with one of my views, I will probably just replace it with an ImagePresenter and associated view. Then all of my graphics code is at the domain level, and I just render it on a canvas for a bitmap, and with some attention to resolution, I can print with the same code. Anything that does not fit with an image presenter, in my experience at least, is a composite where the VC does exactly what one wants. Bill ==================== Jason Johnson jason.johnson.081 at gmail.com wrote: On 8/25/07, tim Rowledge <tim at rowledge.org> wrote: > > As it happens I was one of the reviewers of the original CUA > documents waaaaaay back. It was certainly comprehensive - in my > opinion far too comprehensive. Isn't it always with IBM? :) > Morphic is a reasonable implementation technology but many of the > current widgets built with Morphic are nasty. It would be nice to see > a better bottom layer (under morphic unless anyone wants to rewrite > everything) that can take advantage of OS facilities for accelerated > graphics; Sophie has been using a binding to the Cairo libraries for > example. Tweak has many interesting points but the version Sophie has > been using (and I have no idea how out of date it might be) has been > the cause of much gnashing of teeth when trying to debug or work out > wtf is happening when. > > > tim Yes, with my MVP suggestion I don't mean Morphic couldn't be used. In Dolphin (sorry to harp on it, but it's the best I've ever seen) the view part really feels like a black box, at least to me. I never understood how to create a new widget, and based on how some of the "goodies" widgets looked I don't know if there even was a clean way. So if we had the mechanisms set up for the Model and Presenter objects to communicate to the View space then Morphic or anything else would work as the view. Then we could have a tabbed "chooser" view for selecting Morphs for your GUI you're building. If you create a new Morph you can select what kind of Morph it is and it shows up in the GUI builder after that. I think Tim's idea of cataloging what is there is good. And when we catagorize we would also need to look at implementations so we can document which ones are good to go, and which ones are good in concept only but need a rewrite. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

Not RE: first discussions!
by Gary Chambers 28 Aug '07

28 Aug '07

Ready for a release next week of your UI improvements. Personally I'd like to see this list as a melting pot to gather ideas and go for The Next Generation. Don't get me wrong, Morphic is very powerful, just badgered by clutter and lack of maintenance/refactoring. First thing is to identify the "users" of a framework. No reason we can't accommodate multiple points-of-view... Gary

2 2

State of morphic ( long reply to Sig from [UI] Re: UI plan, my thoughts thread)
by Jerome Peace 27 Aug '07

27 Aug '07

[UI] Re: UI plan, my thoughts Hi Sig, Thanks for your interest and thanks for your questions: >What was fruits which came from morphic team before you stopped developing? Ill let Juan answer this too. The work I did which got into 3.9 was On polygons to smooth out smooth curves and then add optional corners to mixed morphs. On buttons and sliders to fix the targeting mechanisms. This is a key reason why Nouri can do his Easy Morphic Guis now but not before. There is now a way to take a snapshot of any morph and get a thumbnail image that can be resized and which will provide on demand a popup image of the original. There are fixes to internal logic for selecting list items. And double clicking a selected item in an inspector now works as it should. Dans old double click demonstrater has been replaced with an updated version. A major cause of off by one errors and rounding and truncation errors have been identified and language has been introduced to prepare for fixing them. Lots of little fixes. >And what is the current state of morphic package. There are two possible questions here. 1) What is the state of morphic as a whole once it is loaded and in the image? 2) The other is what is the state of the morphic packaging as mcz pieces in the repositories? They need separate answers. Morphic is there and it works in its essential. There are bugs and clutter and annoyances. They dont interfere with most uses. Morphic code could benifit from some code review and refactoring. For large values of some. :-) >Does it have any maintainers? Yes it does. At least one capable one in me. There are others who are adding good things to it. And there of course are the scratch and olpc projects which will be sources of debugged code for future enhancements and widgets. Ill cover future directions in another report. >I have to admit that morphic in its current state requires a clean up. Yes. It requires a review and clean up. It does not require everything to be cleaned up all at once. Slow, steady, progress counts in the long run. And will often produce better results than massivly disruptive efforts. >Maybe starting from a scratch is a good decision. No. Starting from scratch is a terrible decision. Especially when you consider what you are proposing is that someone who is not intimately familiar with morphic start from scratch and build something that is as complex and good as morphic is today. Without the experience to avoid the mistakes that morphic has encountered. Tweak is what you come out with when the most experienced squeak programmer rewrites the interface. With support and with a patron to pay salaries and bills. Juans Morphic 3.0 is an experienced squeak programmers efforts in creating something good based on past experiences. As a Hobby with only self funded resources. With out compatibility with current tools or the ability to use what is as scafolding, it may or may not make it off the ground. It is not something one can hold ones breath for. It can not be ready anytime soon and it will not be easy to integrate when it does come out. Better to start from the annoyances that morphic provices and repair those; keeping the remaining framework in place; and using the exquisite tools that squeak provides to make rapid progress, more and better mistakes and more and better learning experiences. I am leaving out Garys nearly published work, the UI builder that got into 3.9, Nouris gui builder and the potential of lambda message sends which are all important to squeak and morphics future. >Lately in squeak-dev there was note of someone who doing clean-up , >called minimal morphic. He's task was to remove dependencies from >Etoys in basic Morphs package code. This sounds like Juans efforts. The goal while laudable is in practice somewhat unsellable. What benifit is gotten by having less ability in squeak or morphic? And no matter how careful one is in minimizing morphic there will be things that you want that inevitalbly will get broken in an lagre minimization effort. Then you will find your self-funded resources being spent to recreate the stuff you already had. Unless there is a real necessity massive minimization is not something others will wish to adopt. Which covers the state of morphic. Now the other piece the state of morphic MC packages. The current morphic--.mcz package is in size over a megabyte. This is for just the morphic mcz package. Morphic extras and Etoys are separate packages ( I havent looked into their size yet). The size is significant. MC maintainence suffers non-linearly with size. So maintaining Morphic in MC is not on for those with limited resources. (of time and patience). I do my fixes with changesets and goodie fileouts. And relie on more resourced help (Edgar is a brick) to get these into the packages. The packages also need rethinking and reforming. Currently simple fixes are likely to touch several packages at once. The first attempts at packages may not have found the right decouplings between packages. Also how to you repackage glue once its been deployed? I read a lot of Christopher Alexander these days. In the context of image maintence I find the packaging of fixes to be an out of sequence step. I also find that the mcz tool lacks sensativity to levels of scale. That is the very first requirement of a good transformation process. I mention this here because this one change of tool has made morphic maintence a much more difficult task to find resources for. (Though I must admit I have found ways of maintaining morphic that avoids my involvement with the tool.) So part of morphics state is waiting for the tools to become more rational and better suited for squeak and the tasks of squeak development. And another part is trying to get the morphic package better set to be maintained by the current tools. I believe that small whitling steps. Removing leaf classes after understanding their presence is the only way forward that insures morphic continues to work as we make is smaller. Then with a better familiarity the natural decompostion and decouplings can be found. Repair, when done right is implosive, you are left with fewer pieces that work better together and do more that the old buggy stuff. And that direction has the full support of my curiosity. Hth Yours in curiosity and service, --Jerome Peace *** >Igor Stasenko siguctua at gmail.com >Sun Aug 26 13:56:40 UTC 2007 > > >On 26/08/07, Juan Vuletich <juan at jvuletich.org> wrote: >> Hi Bert, >> >> Bert Freudenberg wrote: >> > On Aug 25, 2007, at 19:27 , Juan Vuletich wrote: >> > >> >> I found little support for that from the Board >> > >> > You make that sound like the Board opposed any of this. This is not >> > the case, the Board so far has stayed out of *any* technical advise, >> > it is leaving these to the teams. >> That's true. >> > If anything, there was (unfortunately) little support from the Morphic >> > Team. >> That's not so true. I was the team leader, so support from the Morphic >> Team basically meant support for myself. But what I wanted to do would >> have broken badly back compatibility, and would have caused serious >> trouble to Etoys users. It was a risky decision, with good and bad >> consequences for many people. Too much for the Morphic Team (i.e. for >> myself) to make. That's why I asked the community and the Board for >> support. Basically, the Board didn't take a position, and the community >> (almost all who said something) were against it. >> > >What was fruits which came from morphic team before you stopped developing? >And what is the current state of morphic package, does it have any >maintainers? >I have to admit that morphic in its current state requires a clean up. >Maybe starting from a scratch is a good decision. >Lately in squeak-dev there was note of someone who doing clean-up , >called minimal morphic. He's task was to remove dependencies from >Etoys in basic Morphs package code. > >Maybe first, before new team can start doing something new, its better >to make an overview to think about what is done, what is started but >not finished and what is need to be done? > >> I understand this, and it's ok. It is just that after that, I started >> doing all this in my own fork, the Morphic 3.0 image. >> > *** ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/

2 1

Re: [UI] Re: UI plan, my thoughts
by karl 26 Aug '07

26 Aug '07

> What was fruits which came from morphic team before you stopped > developing? > And what is the current state of morphic package, does it have any > maintainers? Pavel Krivanek has used the Minimal Morphic package, and making the Etoys package loadable. > I have to admit that morphic in its current state requires a clean up. > Maybe starting from a scratch is a good decision. Here is a short summary, not meant to be discouraging. There have been clean up efforts like Morphic stewards. A little happened but after a while it ran out in the sand. There have been a few start from scratch project like Tweak and Morphic 3.0. None of them have catched on. There have also been a few native widgets, native/multiple windows etc. Neither of them have catched on either. > Lately in squeak-dev there was note of someone who doing clean-up , > called minimal morphic. He's task was to remove dependencies from > Etoys in basic Morphs package code. > > Maybe first, before new team can start doing something new, its better > to make an overview to think about what is done, what is started but > not finished and what is need to be done? Brad posted a long list of swiki pages that summarizes much of past efforts. Karl

1 0

UI plan, my thoughts
by Jason Johnson 26 Aug '07

26 Aug '07

Hi all, It was asked that we make a new thread for what we think should be done here so here is mine (the ones we all agree on like consistency not listed here): 1) We need a means of building GUI's graphically. If Squeak is to become viable for building business GUI applications the way Dolphin is/was it making a GUI can't mean writing code describing what widgets to use and where to put them. Even C has good ways to do this graphically. We should to. 2) We need a good framework to build this on. I recommend we look at the Dolphin papers about MVP and use that. It's like MVC but imo factors better (the control and view are merged, but afaik they always were anyway). This sort of thing is easy to overlook, but having a good framework to build on makes it easier to know what classes should have what responsibilities. This is one of the things I feel is wrong in Morphic: it seems as though it wasn't so obvious where the boundaries were between responsibilities. By not having this you end up with.... well what we have now. :) Hrm, well I guess that's it for now. Thanks, Jason

6 8

Old UIs
by Gary Chambers 25 Aug '07

25 Aug '07

A blast from my past.... http://www.flickr.com/photos/12018791@N06/1225910036/ How I love the freedom Smalltalk offers...

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI August 2007