Gary,
Obviously, it is your call. I will admit that Squeak's menus could use a face lift, but I am much more concerned about Morphic/hand weirdness (feel) than the appearance (which has improved over time). So, if they look and work better, I won't complain. If you decide that there are more important battles to fight with the required effort, so be it.
Another slant would be to ask what else you might do for Squeak if you left the menus alone? You might throw some ideas at us to see what resonates as needing work. That said, I am very grateful for your sharing your changes with us, and will happily go along for the ride.
Does that help?
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@btinternet.com 11/19/07 11:49 AM >>>
It will be a quite intrusive set of modifications... Currently, themed menus are available when using the Theme directly (or via the TEasilyThemed trait). This will be about some extensions to UIManager to indirect the creation of menus. Of course, the PSUIManager will use the theme support while the extensions will leave things open.
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
Gary,
Obviously, it is your call. I will admit that Squeak's menus could use a face lift, but I am much more concerned about Morphic/hand weirdness (feel) than the appearance (which has improved over time). So, if they look and work better, I won't complain. If you decide that there are more important battles to fight with the required effort, so be it.
I fixed the Menu hand weirdness in http://bugs.squeak.org/view.php?id=6687
Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this should go in UI enhancements or base Morphic. I use this change set in all my images (and can't live without it anymore). I haven't tried to push it other than by announcing it here (on the UI list) once before.
Will try that as a (feel) start... As for other efforts, I'm game for it... Just the (maybe last) uncharted territory in themeability...
-------
This was a question to gauge the importance of having menus themed as standard, in the general IDE sense... more of fixing what we have rather than the new big thing.
In terms of "the new big thing" I think we have to become very much more focussed. That means really working together. Perhaps everyone could make a prototype system to demonstrate to us all... then work together with the best bits?
As a start, we should be able to easily conform to any particular "look and feel"... take the Java abstraction classes as an example. We could also incorporate "native" (Win32/GTK) as part of the framework (different to the "emulated" Java). I'd really like anything we do to be non-exclusive and all-encompassing, both potentially attainable goals.
Might sound a bit "bloaty" but a framework that can plug-and-play our concepts would be nice...
I think it comes down to the way(s) you want to be able to describe a user-interface. Need to be able to express the intention of the ui in a flexible manner but, also, for some applications, have exact control (plus a lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich enough to do the latter...
There is no easy answer, however... yet. All speculation welcomed!
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Matthew Fulmer Sent: 19 November 2007 8:38 PM To: ui@lists.squeakfoundation.org Subject: [UI] Re: MenuMorph hand weirdness
On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
Gary,
Obviously, it is your call. I will admit that Squeak's menus could use a face lift, but I am much more concerned about Morphic/hand weirdness (feel) than the appearance (which has improved over time). So, if they look and work better, I won't complain. If you decide that there are more important battles to fight with the required effort, so be it.
I fixed the Menu hand weirdness in http://bugs.squeak.org/view.php?id=6687
Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this should go in UI enhancements or base Morphic. I use this change set in all my images (and can't live without it anymore). I haven't tried to push it other than by announcing it here (on the UI list) once before.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
I'm not the experpert on how and where to start with a *general* UI framwork but I follow Gary's invitation to "All speculation welcomed".
Having read the LivelyKernel-SourceCode-0.7, I noticed the following (list not necessarily complete):
- orientated towards a possible WebOS - resources have URL (basic interoperability of material) - imports, exports to/from other of the same kind - graphical base objects out of the SVG box - SVG+style is teachable to/learnable by the masses - widgets look easy to use/reuse - small # of support classes besides the UI framework - worlds, hands, morphs, ticks are shoulders+neck of that Atlas - Events / bindings are like a scripter expects them - no observable restrictions to animations (limited only by SVG, good) - things can be glued together without headaches, within the limitations (good) of SVG
For sure some of the concepts of LivelyKernel require that mixIns/traits are supported but, who cares with a dynamic language and living objects.
And there is that remarkable comment, "my kingdom for a Smalltalk block!" in Core.js :-D
So my question is, how about borrowing some things from LivelyKernel?
/Klaus
On Tue, 20 Nov 2007 02:50:22 +0100, Gary Chambers wrote:
Will try that as a (feel) start... As for other efforts, I'm game for it... Just the (maybe last) uncharted territory in themeability...
This was a question to gauge the importance of having menus themed as standard, in the general IDE sense... more of fixing what we have rather than the new big thing.
In terms of "the new big thing" I think we have to become very much more focussed. That means really working together. Perhaps everyone could make a prototype system to demonstrate to us all... then work together with the best bits?
As a start, we should be able to easily conform to any particular "look and feel"... take the Java abstraction classes as an example. We could also incorporate "native" (Win32/GTK) as part of the framework (different to the "emulated" Java). I'd really like anything we do to be non-exclusive and all-encompassing, both potentially attainable goals.
Might sound a bit "bloaty" but a framework that can plug-and-play our concepts would be nice...
I think it comes down to the way(s) you want to be able to describe a user-interface. Need to be able to express the intention of the ui in a flexible manner but, also, for some applications, have exact control (plus a lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich enough to do the latter...
There is no easy answer, however... yet. All speculation welcomed!
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Matthew Fulmer Sent: 19 November 2007 8:38 PM To: ui@lists.squeakfoundation.org Subject: [UI] Re: MenuMorph hand weirdness
On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
Gary,
Obviously, it is your call. I will admit that Squeak's menus could
use
a face lift, but I am much more concerned about Morphic/hand weirdness (feel) than the appearance (which has improved over time). So, if
they
look and work better, I won't complain. If you decide that there are more important battles to fight with the required effort, so be it.
I fixed the Menu hand weirdness in http://bugs.squeak.org/view.php?id=6687
Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this should go in UI enhancements or base Morphic. I use this change set in all my images (and can't live without it anymore). I haven't tried to push it other than by announcing it here (on the UI list) once before.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
The "big thing" just got bigger :-)...
Some thoughts on this...
Having read the LivelyKernel-SourceCode-0.7, I noticed the following (list not necessarily complete):
- orientated towards a possible WebOS
have a clear separation between ui definition and presentation
- resources have URL (basic interoperability of material)
URIs would be good to adopt, any ui element can be described via a URI
- imports, exports to/from other of the same kind
not sure quite what you mean here Klaus
- graphical base objects out of the SVG box
have done a bit with SVG (as far as Balloon could manage, Cairo would be a nice alternative presentation layer, still use Balloon for fallback (with limitations) for platforms that don't support Cairo (pdas etc).
- SVG+style is teachable to/learnable by the masses
and is a standard. would be nice
- widgets look easy to use/reuse
indeed... a better composite model would be nice (wishes I coul plug in different fillStyles at the moment... since they go to the lowest level it is not currently possible to define a new type of fillStyle that is composited programatically)
- small # of support classes besides the UI framework
with the right framework there'd probably be no "extra" support classes
- worlds, hands, morphs, ticks are shoulders+neck of that Atlas
or just one kind of head-of-the-hydra
- Events / bindings are like a scripter expects them
when...do... but also asynchronous, like updatingXXMorph - an independent observer
- no observable restrictions to animations (limited only by SVG, good)
down to the in-framework support classes
- things can be glued together without headaches, within the limitations (good) of SVG
perhaps no complex interfaces, just individual aspects that can be combined
For sure some of the concepts of LivelyKernel require that mixIns/traits are supported but, who cares with a dynamic language and living objects.
And there is that remarkable comment, "my kingdom for a Smalltalk block!"
I like that one!
So my question is, how about borrowing some things from LivelyKernel?
indeed...
Forgot to comment a bit on my thoughts about SVG (when used within the UI framework). I see it [SVG] as a good way to constrain/limit the things which can possibly addressed by a new UI. Did not mean to implement it, just use it as a stop condition (i.e. what not to do/address when developing a framework).
On Tue, 20 Nov 2007 15:37:39 +0100, Gary Chambers wrote:
Some thoughts on this...
Having read the LivelyKernel-SourceCode-0.7, I noticed the following (list not necessarily complete):
- orientated towards a possible WebOS
have a clear separation between ui definition and presentation
- resources have URL (basic interoperability of material)
URIs would be good to adopt, any ui element can be described via a URI
- imports, exports to/from other of the same kind
not sure quite what you mean here Klaus
Was meant to just do enough to export from a system with new UI framework to another system with same UI framework, but more than just fileOut/fileIn of source code. Perhaps just enough to make one system [computer] that can serve components to clients via some connection.
- graphical base objects out of the SVG box
have done a bit with SVG (as far as Balloon could manage, Cairo would be a nice alternative presentation layer, still use Balloon for fallback (with limitations) for platforms that don't support Cairo (pdas etc).
- SVG+style is teachable to/learnable by the masses
and is a standard. would be nice
- widgets look easy to use/reuse
indeed... a better composite model would be nice (wishes I coul plug in different fillStyles at the moment... since they go to the lowest level it is not currently possible to define a new type of fillStyle that is composited programatically)
- small # of support classes besides the UI framework
with the right framework there'd probably be no "extra" support classes
:)
- worlds, hands, morphs, ticks are shoulders+neck of that Atlas
or just one kind of head-of-the-hydra
:-))
- Events / bindings are like a scripter expects them
when...do... but also asynchronous, like updatingXXMorph - an independent observer
Sure.
- no observable restrictions to animations (limited only by SVG, good)
down to the in-framework support classes
- things can be glued together without headaches, within the limitations (good) of SVG
perhaps no complex interfaces, just individual aspects that can be combined
Sounds good. But raises questions, what+how. Roles? More general? More specific?
For sure some of the concepts of LivelyKernel require that mixIns/traits are supported but, who cares with a dynamic language and living objects.
And there is that remarkable comment, "my kingdom for a Smalltalk block!"
I like that one!
So my question is, how about borrowing some things from LivelyKernel?
indeed...
I think basing a UI on SVG would be a great idea. Proper rounded corners for a start ;-) Not to mention, being vector-based for adapting to screen/printer/visual-device resolution. As the thme stuff has gone on, generally resticting to shapes/gradients has worked well. Of course, some things are easier with bitmaps but that's down to the current (somewhat) limited support for vector graphics in Balloon.
I might dig out the old-slow-code I did for SVG on top of Balloon... (SVGMorph on SqueakMap). Was pretty experimental but had at least one satisfied user!
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Klaus D. Witzel Sent: 20 November 2007 3:06 PM To: ui@lists.squeakfoundation.org Subject: [UI] Re: "the new big thing" [was: MenuMorph hand weirdness]
Forgot to comment a bit on my thoughts about SVG (when used within the UI framework). I see it [SVG] as a good way to constrain/limit the things which can possibly addressed by a new UI. Did not mean to implement it, just use it as a stop condition (i.e. what not to do/address when developing a framework).
On Tue, 20 Nov 2007 15:37:39 +0100, Gary Chambers wrote:
Some thoughts on this...
Having read the LivelyKernel-SourceCode-0.7, I noticed the following (list not necessarily complete):
- orientated towards a possible WebOS
have a clear separation between ui definition and presentation
- resources have URL (basic interoperability of material)
URIs would be good to adopt, any ui element can be
described via a URI
- imports, exports to/from other of the same kind
not sure quite what you mean here Klaus
Was meant to just do enough to export from a system with new UI framework to another system with same UI framework, but more than just fileOut/fileIn of source code. Perhaps just enough to make one system [computer] that can serve components to clients via some connection.
- graphical base objects out of the SVG box
have done a bit with SVG (as far as Balloon could manage,
Cairo would
be a nice alternative presentation layer, still use Balloon for
fallback (with
limitations) for platforms that don't support Cairo (pdas etc).
- SVG+style is teachable to/learnable by the masses
and is a standard. would be nice
- widgets look easy to use/reuse
indeed... a better composite model would be nice (wishes I
coul plug in
different fillStyles at the moment... since they go to the
lowest level
it is not currently possible to define a new type of fillStyle that is composited programatically)
- small # of support classes besides the UI framework
with the right framework there'd probably be no "extra"
support classes
:)
- worlds, hands, morphs, ticks are shoulders+neck of that Atlas
or just one kind of head-of-the-hydra
:-))
- Events / bindings are like a scripter expects them
when...do... but also asynchronous, like updatingXXMorph - an independent observer
Sure.
- no observable restrictions to animations (limited only by SVG, good)
down to the in-framework support classes
- things can be glued together without headaches, within the limitations (good) of SVG
perhaps no complex interfaces, just individual aspects that can be combined
Sounds good. But raises questions, what+how. Roles? More general? More specific?
For sure some of the concepts of LivelyKernel require that
mixIns/traits
are supported but, who cares with a dynamic language and
living objects.
And there is that remarkable comment, "my kingdom for a Smalltalk block!"
I like that one!
So my question is, how about borrowing some things from LivelyKernel?
indeed...
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
On Nov 20, 2007 2:50 AM, Gary Chambers gazzaguru2@btinternet.com wrote:
This was a question to gauge the importance of having menus themed as standard, in the general IDE sense... more of fixing what we have rather than the new big thing.
In terms of "the new big thing" I think we have to become very much more focussed. That means really working together. Perhaps everyone could make a prototype system to demonstrate to us all... then work together with the best bits?
As a start, we should be able to easily conform to any particular "look and feel"... take the Java abstraction classes as an example. We could also incorporate "native" (Win32/GTK) as part of the framework (different to the "emulated" Java). I'd really like anything we do to be non-exclusive and all-encompassing, both potentially attainable goals.
Might sound a bit "bloaty" but a framework that can plug-and-play our concepts would be nice...
I think this is all very doable within MVP and in fact MVP would make this sort of thing much easier to do, since very little if any code would depend on what view was being used.
I think it comes down to the way(s) you want to be able to describe a user-interface. Need to be able to express the intention of the ui in a flexible manner but, also, for some applications, have exact control (plus a lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich enough to do the latter...
Personally I prefer to use a graphical tool to draw exactly the interface I want, but different people want different things, so having a nice framework that can support all of us is the answer I believe.
-
Bill Schwab -
Gary Chambers -
Gary Chambers -
Jason Johnson -
Klaus D. Witzel -
Matthew Fulmer