First, I am not aware that anything is being done in the dark. However, Object Arts did pretty well with MVP w/o a lot of input, so maybe a small group _should_ be working behind closed doors. Indeed, the technology that seeded this effort came from a well-intentioned and skilled group of people at Pinesoft. Please note that they have made substantial changes based on our feedback, and this thread started with them asking for input on a future change. It's working; let's not derail them.
Sincerely,
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
siguctua@gmail.com 02/16/08 4:53 PM >>>
I'd like to add, it wouldn't hurt to discuss design of new framework publicly, so everyone will have a chance to put his 2 cents and share ideas. :)
On 16/02/2008, Bill Schwab BSchwab@anest.ufl.edu wrote:
Tim,
Agreed, and then some. I would not be upset by a framework that can work down to the individual widget, but what you describe would give most of the benefits of host integration and very few of the hassles. In that, I am assuming (a safe bet I think) that Gary will ensure that the feel is sufficiently configurable that we will not need an outside framework to impose discipline re keyboard focus, etc.
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
tim@rowledge.org 02/15/08 3:00 PM >>>
Our basic intent when designing Ffenestri was to allow pretty much any usage. If you want to map a single SystemWindow level object to a host window then that would be good and would match most needs in typical applications. Don't forget to consider floating palette type windows as well - those that accompany a main window and provide a palette of tool icons etc. And menus could be implemented by opening a short lived small window; this might well be much simpler and more portable than trying to hook cleanly into every OS menu api, whilst allowing the menu to be taller than a small app. window if needed.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 10) "This code is a piece of crap! You have no honor!"
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
We are certainly up for discussion/design with this... I am coming to the position of sandboxing a potential new framework as a Morph... like a high level independent window system that takes it's initial basis via an adaptor morph that translates various morphic events to its own metaphor. This would be an aside from restructuring the low-level event mechanism, for the moment, while providing a means to explore new and (hopefully) more efficient/flexible frameworks for providing a user interface.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 17 February 2008 1:07 PM To: ui@lists.squeakfoundation.org Subject: Re: [UI] Morphic restructuring
First, I am not aware that anything is being done in the dark. However, Object Arts did pretty well with MVP w/o a lot of input, so maybe a small group _should_ be working behind closed doors. Indeed, the technology that seeded this effort came from a well-intentioned and skilled group of people at Pinesoft. Please note that they have made substantial changes based on our feedback, and this thread started with them asking for input on a future change. It's working; let's not derail them.
Sincerely,
Bill
Once we have a nice performant and flexible framework I see the roles being reversed, Morphic being handled via an adaptor in the new framework...
All thoughts welcome. Gary.