UI

ui@lists.squeakfoundation.org

251 discussions

C# methodologies
by Jason Johnson 13 Jan '08

13 Jan '08

Hi all, Have any of you used C#? I mean in depth? I just inherited a C# project at my job and I must say I'm impressed. I had previously written it off as just Java++. I bring this up because they have some things that might be nice in Smalltalk as well. One of the things I figured out a good use for this weekend is "extended properties". You can define properties on your own classes that will show up in the property browser when your class is dropped onto a form, but what an extended property does is show up in *other components* property windows. The use case here for me was, I need any component on my form that implements the "configuration" interface to get registered with a configuration management class so that I don't have to hard code which components are persisted. This was not nearly as easy as it sounds since in C# I can't just modify Component to send a new e.g. "persist configuration" event. But with an extended property I just make a ConfigurationManager class and say that it extends it's property to any class that implements my config interface. The nice thing about it is, due to how the code is generated by the RAD, components buried deep in forms can't find out what component they are contained in inside their own constructors, but an extended property is applied at the top level form (well, actually at the location the property extension class is) so the code looks like (in smalltalk syntax): TopForm>>initialize configManager register: someComponent instead of how a property would normally be applied: SomeComponent>>initialize self registerWith: configManager "doesn't work because I can't get a handle configManager. It's an instance variable in TopForm which I can't reference until long after this method finishes". Maybe I am just new to RAD development and RAD's have always been this way, but the C# environment feels to me like it takes OO design to the RAD level as well. That is, in this environment I write most of my code to create components that can have the specific information put in from the RAD, so that all code I'm responsible for is always generic. Specifics are always entered in the RAD. The environment lets me do things like, if I notice that an information grid always has (1) a fancy title bar, (2) a "view" to connect to a back end database and (3) a filter, I can create a "control" that consists of these units, set it up to only display the properties that I want to expose from these child components and there after only drop this new component on my forms. Extending reuse to the RAD realm. Bill, did Dolphin have something like this? I didn't get so far in it, but I never saw anything like it in my explorations. I'm sure it could be done with code, but this was build totally graphically (except setting up properties), and from a business point of view the biggest concern is keeping the lines code we are responsible for managing as low as we can. In the best case we would only have business logic. Another nice thing that aids in this area is the way the inheritance is set up: "Component" is the root class for things that show up in the toolbox (the place you find things to drop on your form) but components go in a special box under the form (called the component tray) because they have no visual representation. A "control" is a subclass of component that does have a graphical display so it can be placed directly on a form. This lets you hook up "presenter" style components (i.e. things that have no graphical representation) to "view" style controls (i.e. things that do) completely in the RAD. The "not as good": C# has something they call "design mode" that basically means the code you write runs inside the IDE to let you fully extend the IDE with your new components. A consequence of this is when ever you make a component (or change an existing one) you have to recompile your project before it shows up anywhere. Another consequence is that if you have a typo you lock up the whole IDE and you can't set breakpoints and things without running a separate IDE pointing at your main one to debug it. In other words, a Smalltalker really feels the pain of the difference between design time and runtime, but it's better then nothing. So what do you all think? I think a system like this in Smalltalk could be really powerful. We would have to take a different strategy to implement of course [1] but I think we could make a system with unprecedented productivity. Or maybe I'm just infatuated with this new toy. :) But there must be something good here we could learn from. Thanks, Jason [1] My initial thought here is, a form running "in the wild" gets its signals from the VM (or whatever), but one that is being designed would need the designer to stand between it and the normal mechanism and change how the events are sent a little, or not forward them at all in some cases. E.g. if you click a button in the application it does what it is supposed to do, but in the designer clicking a button would have totally different behavior. C# deals with this situation by having a property called "DesignMode" that components must check in functions that need special behavior under the designer, but that doesn't strike me as very elegant. I like the idea of the design environment controlling what the form components see so that components are written without thinking about such issues. I also hope we can come up with something more sophisticated then the code generation they have done or the XML generation and run time loading of it that I understand will be in .Net 3.0. Serializing the objects the same way they are serialized when one saves the image would probably work, so long as there is no issue with "resurrecting" a given object multiple times for different forms. Dolphin did something to this effect, no?

1 0

[Bug 6802] Bug with ScriptManager scrollbars
by Damien Cassou 08 Jan '08

08 Jan '08

Hi, I've just submitted a bug report: http://bugs.squeak.org/view.php?id=6802 each time I generate a squeak-dev image with UI-Enhancements, a graphical bug appears in the ScriptManager. Attached is a screen shot. You can download an image and see by yourself: ftp://ftp.ofset.org/squeak/squeak-dev/beta/sq3.10-7159dev07.12.1.zip Bye -- Damien Cassou

2 3

RE: [UI] More feel observations
by Bill Schwab 05 Dec '07

05 Dec '07

Gary, That would be great, though please leave out the activation, Windows Genuine Annoyance(TM), black screen of death, slow copies, etc. ;) It certainly is not a high priority, but would be appreciated. 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 >>> gazzaguru2(a)btinternet.com 12/5/2007 1:24:18 PM >>> I could do a "VistaryBasic" subclass, just like ms, lol! > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 05 December 2007 6:05 PM > To: ui(a)lists.squeakfoundation.org > Subject: RE: [UI] More feel observations > > > Gary, > > My v-key complaints are mostly limited to the numeric keypad, but I > _think_ it is a little broader than that. Indeed, the Windows VM does a > better job, even getting stuff like control-shift-arrow to work > properly, at least as far as I use them. Just so I do not sound like a > walking shortcut table, some of the weird sequences get exercised in > proportion to the editing task. I re-learn them in a hurry, when > appropriate. Home and end are staples. > > Vistary: I have been doing most of my Squeak hacking on a 1.8 GHz P4 w/ > 512MB, or so it claims. It is an older machine, and is becoming my bit > bucket, which Gnome finds a little taxing. A preference for > translucency might be nice. The truth is, even when the hardware is up > to it, I find the translucency a little distracting, especially on > walkbacks. > > > > (PluggableListMorph used to release > > the keyboard focus regardless!). > > Thanks for fixing that, and more. I will take another look at the > preferences. Maybe I have too much of a good thing in use?? > > 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 > > > >>> gazzaguru2(a)btinternet.com 12/5/2007 6:09:51 AM >>> > Thanks for feedback, I'll make some comments... > > > -----Original Message----- > > From: ui-bounces(a)lists.squeakfoundation.org > > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill > Schwab > > Sent: 05 December 2007 2:11 AM > > To: ui(a)lists.squeakfoundation.org > > Subject: [UI] More feel observations > > > > > > Gary, > > > > I did some more "real" programming today (working on a port of my > > home-grown file backup system), and am starting to find that one of > my > > larger complaints (which I consider to be a sign of progress) is the > > apparent lack of support for virtual keys - the home and end in > > particular - in the unix VM. My searching so far has not turned up > > anything specifically useful, so I will probably submit a question > to > > Squeak-dev soon. > > Yes, virtual keys... my main gripe is lack of support for function > keys. > As for home/end what's the problem with those? Or do you mean just on > the > numeric keypad? (only just noticed now you mention it... ok in Windows > though :-) ). > > > > > Vistary, at least on my hardware, is slow enough that I can easily > type > > faster than it can keep up. Soft squeak is much harder to outrun on > the > > same hardware. Note that I still cannot fully clobber it due to the > > virtual key hassles. Part of my input speed comes from > > home/tab/past/space/etc/end, sometimes with shift depressed to make > > selections. Some of this stuff is so engrained I don't even realize I > do > > it until it doesn't work. > > Been a while since I noticed any keyboard lag from Squeak... > SoftSqueak is certainly the most responsive theme, more than > StandardSqueak. > Vistary, due to translucency, is only expected to work well on modern > hardware (is fine on my 1.73 GHz Centrino laptop). What's your > hardware? > > > > > One thing that is in our general area is mouse interaction. It will > be > > difficult to catch this in the act, but there is pretty clearly > > something to it. Have some code in plain sight; now try to > drag-select > > it, quickly. I get unpredictable results; sometimes it selects what > I > > want, usually it does not. When I have had similar problems in > other > > systems, it suggests that the code is picking up current mouse > > coordinates when it should be using event coordinates. > > Not noticed any problems like this... of course, a slower system might > highlight such issues. > > > Re #mouseClickForKeyboardFocus, it appears to be selectively > necessary. > > AFAICT, with other changes you have made, it is somewhat redundant. > The > > message name browser is horribly broken without it. A few times, I > have > > found that when adding methods, I get into a situation where the > input > > focus is undefined, or not where I want it anyway, making it > necessary > > to click in the code pane of the system browser. The weird thing is > > that in that situation, the cursor needs to be in the code pane for > it > > to get focus. I have #mouseClickForKeyboardFocus set to true. > > Best to set #mouseOverForKeyboardFocus to false when > #mouseClickForKeyboardFocus is enabled (see > PluggableTextMorph>>mouseLeave:). I'll probably rework that method > since it > is now the only sender of #mouseOverForKeyboardFocus > (PluggableListMorph > used to release the keyboard focus regardless!). Or, possibly, make > changes > to properly honour the #mouseOverForKeyboardFocus pref in the usual > morphs > (lists, text etc.). > > > > > Sorry for the incomplete observations and guesswork, but it is > hopefully > > better to write down what I can remember. > > > > Bill > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

RE: [UI] More feel observations
by Bill Schwab 05 Dec '07

05 Dec '07

Gary, My v-key complaints are mostly limited to the numeric keypad, but I _think_ it is a little broader than that. Indeed, the Windows VM does a better job, even getting stuff like control-shift-arrow to work properly, at least as far as I use them. Just so I do not sound like a walking shortcut table, some of the weird sequences get exercised in proportion to the editing task. I re-learn them in a hurry, when appropriate. Home and end are staples. Vistary: I have been doing most of my Squeak hacking on a 1.8 GHz P4 w/ 512MB, or so it claims. It is an older machine, and is becoming my bit bucket, which Gnome finds a little taxing. A preference for translucency might be nice. The truth is, even when the hardware is up to it, I find the translucency a little distracting, especially on walkbacks. > (PluggableListMorph used to release > the keyboard focus regardless!). Thanks for fixing that, and more. I will take another look at the preferences. Maybe I have too much of a good thing in use?? 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 >>> gazzaguru2(a)btinternet.com 12/5/2007 6:09:51 AM >>> Thanks for feedback, I'll make some comments... > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 05 December 2007 2:11 AM > To: ui(a)lists.squeakfoundation.org > Subject: [UI] More feel observations > > > Gary, > > I did some more "real" programming today (working on a port of my > home-grown file backup system), and am starting to find that one of my > larger complaints (which I consider to be a sign of progress) is the > apparent lack of support for virtual keys - the home and end in > particular - in the unix VM. My searching so far has not turned up > anything specifically useful, so I will probably submit a question to > Squeak-dev soon. Yes, virtual keys... my main gripe is lack of support for function keys. As for home/end what's the problem with those? Or do you mean just on the numeric keypad? (only just noticed now you mention it... ok in Windows though :-) ). > > Vistary, at least on my hardware, is slow enough that I can easily type > faster than it can keep up. Soft squeak is much harder to outrun on the > same hardware. Note that I still cannot fully clobber it due to the > virtual key hassles. Part of my input speed comes from > home/tab/past/space/etc/end, sometimes with shift depressed to make > selections. Some of this stuff is so engrained I don't even realize I do > it until it doesn't work. Been a while since I noticed any keyboard lag from Squeak... SoftSqueak is certainly the most responsive theme, more than StandardSqueak. Vistary, due to translucency, is only expected to work well on modern hardware (is fine on my 1.73 GHz Centrino laptop). What's your hardware? > > One thing that is in our general area is mouse interaction. It will be > difficult to catch this in the act, but there is pretty clearly > something to it. Have some code in plain sight; now try to drag-select > it, quickly. I get unpredictable results; sometimes it selects what I > want, usually it does not. When I have had similar problems in other > systems, it suggests that the code is picking up current mouse > coordinates when it should be using event coordinates. Not noticed any problems like this... of course, a slower system might highlight such issues. > Re #mouseClickForKeyboardFocus, it appears to be selectively necessary. > AFAICT, with other changes you have made, it is somewhat redundant. The > message name browser is horribly broken without it. A few times, I have > found that when adding methods, I get into a situation where the input > focus is undefined, or not where I want it anyway, making it necessary > to click in the code pane of the system browser. The weird thing is > that in that situation, the cursor needs to be in the code pane for it > to get focus. I have #mouseClickForKeyboardFocus set to true. Best to set #mouseOverForKeyboardFocus to false when #mouseClickForKeyboardFocus is enabled (see PluggableTextMorph>>mouseLeave:). I'll probably rework that method since it is now the only sender of #mouseOverForKeyboardFocus (PluggableListMorph used to release the keyboard focus regardless!). Or, possibly, make changes to properly honour the #mouseOverForKeyboardFocus pref in the usual morphs (lists, text etc.). > > Sorry for the incomplete observations and guesswork, but it is hopefully > better to write down what I can remember. > > Bill _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

More feel observations
by Bill Schwab 05 Dec '07

05 Dec '07

Gary, I did some more "real" programming today (working on a port of my home-grown file backup system), and am starting to find that one of my larger complaints (which I consider to be a sign of progress) is the apparent lack of support for virtual keys - the home and end in particular - in the unix VM. My searching so far has not turned up anything specifically useful, so I will probably submit a question to Squeak-dev soon. Vistary, at least on my hardware, is slow enough that I can easily type faster than it can keep up. Soft squeak is much harder to outrun on the same hardware. Note that I still cannot fully clobber it due to the virtual key hassles. Part of my input speed comes from home/tab/past/space/etc/end, sometimes with shift depressed to make selections. Some of this stuff is so engrained I don't even realize I do it until it doesn't work. One thing that is in our general area is mouse interaction. It will be difficult to catch this in the act, but there is pretty clearly something to it. Have some code in plain sight; now try to drag-select it, quickly. I get unpredictable results; sometimes it selects what I want, usually it does not. When I have had similar problems in other systems, it suggests that the code is picking up current mouse coordinates when it should be using event coordinates. Re #mouseClickForKeyboardFocus, it appears to be selectively necessary. AFAICT, with other changes you have made, it is somewhat redundant. The message name browser is horribly broken without it. A few times, I have found that when adding methods, I get into a situation where the input focus is undefined, or not where I want it anyway, making it necessary to click in the code pane of the system browser. The weird thing is that in that situation, the cursor needs to be in the code pane for it to get focus. I have #mouseClickForKeyboardFocus set to true. Sorry for the incomplete observations and guesswork, but it is hopefully better to write down what I can remember. 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

Re: [UI] Native vs. portable widgets: Eclipse SWT
by Bill Schwab 30 Nov '07

30 Nov '07

Matt, I suspect the author is heavily biased toward native widgets. Note the assumption that they will out-perform emulated widgets. All it takes to turn that around is a good VM, careful coding on the emulation layer, and a carelessly written native widget library and/or one heavy on eye candy. Depending on the design of the native platform, emulated widgets can shortcut cumbersome uses of a message queue to gain a design advantage. It is not at all clear that native widgets will always win on speed, especially on "older" hardware. That said, I have no objection to making native widgets available. If for no other reason, some native widget discipline might be good for Squeak, and there are times when it would be nice to have one native window per system window - and other times when that would be wasteful. Since we already have emulated widgets, "all" we need to do is keep them alive while enhancing native widget support. I believe that should be our goal. With MVP, switching between them probably should be as simple as changing the view hierarchy to be used. 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 >>> tapplek(a)gmail.com 11/29/07 3:21 PM >>> I found this FAQ entry for Eclipse very interesting: http://wiki.eclipse.org/FAQ_Why_does_Eclipse_use_SWT%3F It discusses the merits of both native and portable widgets, and why eclipse chose the native SWT rather than the portable Swing. This may be obvious flamebait, but it could also be interesting. First person to reply is banned from planet Jupiter ;). -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Native vs. portable widgets: Eclipse SWT
by Matthew Fulmer 29 Nov '07

29 Nov '07

I found this FAQ entry for Eclipse very interesting: http://wiki.eclipse.org/FAQ_Why_does_Eclipse_use_SWT%3F It discusses the merits of both native and portable widgets, and why eclipse chose the native SWT rather than the portable Swing. This may be obvious flamebait, but it could also be interesting. First person to reply is banned from planet Jupiter ;). -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

1 0

Re: [UI] Streams - a beginning
by Bill Schwab 29 Nov '07

29 Nov '07

Damien, Fair enough. Email will probably be easiest; Squeak-dev is busy enough to swamp us. 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 >>> damien.cassou(a)gmail.com 11/28/07 9:49 AM >>> 2007/11/28, Bill Schwab <BSchwab(a)anest.ufl.edu>: > Damien, > > Understood, but the API can always be reproduced in terms of their > existing classes. Yes, and you can flatten the traits inside the classes. > Is there a preferred forum for discussing Nile? squeak-dev is ok I think. Since, I'm the only developper and there is no user at all, we can also talk by mail :-). -- Damien Cassou _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 2

Re: [UI] Streams - a beginning
by Bill Schwab 28 Nov '07

28 Nov '07

Damien, Understood, but the API can always be reproduced in terms of their existing classes. Is there a preferred forum for discussing Nile? 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 >>> damien.cassou(a)gmail.com 11/28/07 6:25 AM >>> 2007/11/27, Bill Schwab <BSchwab(a)anest.ufl.edu>: > Damien, > > I am far more interested in compatibility with VW and Dolphin (which > tends to follow VW in such areas) than with strict ANSI compatibility. > In the case of exhaustion, it sure seemed to me that ANSI did not > specify an error - I am convinced that Dolphin and VW have it right. > > I will take a long look at Nile. Thanks! Nile uses Traits and Traits are not available under other Smalltalk dialects. -- Damien Cassou _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

Re: [UI] Streams - a beginning
by Bill Schwab 28 Nov '07

28 Nov '07

Damien, I am far more interested in compatibility with VW and Dolphin (which tends to follow VW in such areas) than with strict ANSI compatibility. In the case of exhaustion, it sure seemed to me that ANSI did not specify an error - I am convinced that Dolphin and VW have it right. I will take a long look at Nile. 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 >>> damien.cassou(a)gmail.com 11/27/2007 9:38 AM >>> 2007/11/27, Bill Schwab <BSchwab(a)anest.ufl.edu>: > I have been aware of Flow for some time, but have reasons to avoid it, > at least for now. When I tried it some time ago, Nile did not raise any > type of exception on reading off the end of a stream (and AFAIK, I was > using its streams vs. Squeak's). I have since seen that is supposed to > work, so I will take another look. It still does not raise any exception because this is what ANSI says IIRC. But I don't really care about ANSI anymore so if you want to change the behavior of Nile please do and commit to the main repository. Nile is designed to be easily changeable and extendable. -- Damien Cassou _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI