Menu
▾
▴
adobe-source-devel
|
From: Foster T. B. <fbr...@ad...> - 2006-02-15 00:06:25
|
All, Ralph Thomas and I have begun designing a picture widget for ASL. This widget will cover icons in a generic way as well. The in- development design is posted at: <http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView> We would welcome any commentary, feedback, and/or refinement on the design or the documentation. If anyone would like to contribute please provide it either by email to the ASL mailing list or on the Wiki page directly. If you do not have write access to the Wiki page yet please create a Wiki account; once that is done email me and I will authorize you. Thanks in advance for any time you can give to the effort. Blessings, Foster -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Tony V. E. <to...@ad...> - 2006-02-15 00:29:18
|
I have a ProportionalFit<number_type> template that might help with the proportional resizing. I can email it to you. I did a image view control once that also implemented the image interface - ie acxted like an image in that you could call CopyImage(view, image) (which takes 2 image * params) to put an image into it, etc. Interesting idea, anyhow. The import/export procs will eventually need to handle options. Do you expect the import/export procs to bring up UI, or should you pass in a dictionary_t of params to the export funcs, or something like that? Tony Van Eerd Adobe Waterloo -via Thunderbird- Foster T. Brereton wrote: > All, > > Ralph Thomas and I have begun designing a picture widget for ASL. This > widget will cover icons in a generic way as well. The in- development > design is posted at: > > <http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView> > > We would welcome any commentary, feedback, and/or refinement on the > design or the documentation. If anyone would like to contribute please > provide it either by email to the ASL mailing list or on the Wiki page > directly. If you do not have write access to the Wiki page yet please > create a Wiki account; once that is done email me and I will authorize > you. > > Thanks in advance for any time you can give to the effort. > > Blessings, > Foster > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > |
|
From: Foster T. B. <fbr...@ad...> - 2006-02-15 01:06:42
|
On Feb 14, 2006, at 04:22p, Tony Van Eerd wrote: > I have a ProportionalFit<number_type> template that might help with > the proportional resizing. I can email it to you. Ah, this is interesting. Would it make a good addition to ASL as a generic algorithm? GIL might have something like this in it already, too, I'm not sure (sadly I haven't looked over the API as thoroughly as I ought). > I did a image view control once that also implemented the image > interface - ie acxted like an image in that you could call CopyImage > (view, image) (which takes 2 image * params) to put an image into > it, etc. Interesting idea, anyhow. Interesting. Are you familiar with Lubomir and Hailin's work on GIL? How would what you are describing compare to what it has to offer? > The import/export procs will eventually need to handle options. Do > you expect the import/export procs to bring up UI, or should you > pass in a dictionary_t of params to the export funcs, or something > like that? This is a good question. I'd expect the functions to be able to run without user intervention (so scripting parameters should be able to be passed), but the possibility of popping a UI to detail further command parameters is not out of the question. I'll have to think a bit more about this one. Incidentally we have recently released a modal dialog interface API that accomplishes this very task pretty handily, so leveraging that might be good. > Tony Van Eerd > Adobe Waterloo > -via Thunderbird- > > Foster T. Brereton wrote: >> All, >> Ralph Thomas and I have begun designing a picture widget for ASL. >> This widget will cover icons in a generic way as well. The in- >> development design is posted at: >> <http://opensource.adobe.com/twiki/bin/view/AdobeSource/ >> PictureView> >> We would welcome any commentary, feedback, and/or refinement on >> the design or the documentation. If anyone would like to >> contribute please provide it either by email to the ASL mailing >> list or on the Wiki page directly. If you do not have write >> access to the Wiki page yet please create a Wiki account; once >> that is done email me and I will authorize you. >> Thanks in advance for any time you can give to the effort. >> Blessings, >> Foster >> -- >> Foster T. Brereton <}}}>< Romans 3:21-26 >> A d o b e S o f t w a r e T e c h n o l o g y L a b >> "What 99 percent of programmers need to know is not how to build >> components but how to use them." -- Alexander Stepanov -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Tony V. E. <to...@ad...> - 2006-02-15 02:06:29
|
Tony Van Eerd Adobe Waterloo -via Thunderbird- Foster T. Brereton wrote: > On Feb 14, 2006, at 04:22p, Tony Van Eerd wrote: > >> I have a ProportionalFit<number_type> template that might help with >> the proportional resizing. I can email it to you. > > > Ah, this is interesting. Would it make a good addition to ASL as a > generic algorithm? GIL might have something like this in it already, > too, I'm not sure (sadly I haven't looked over the API as thoroughly as > I ought). > I think it, or some other generic prop-fit solution, should be in ASL - I wrote mine because I saw prop-fit code being rewritten (with bugs) over and over. I've sent it to you in another email. Do as you please. >> I did a image view control once that also implemented the image >> interface - ie acxted like an image in that you could call CopyImage >> (view, image) (which takes 2 image * params) to put an image into it, >> etc. Interesting idea, anyhow. > > > Interesting. Are you familiar with Lubomir and Hailin's work on GIL? > How would what you are describing compare to what it has to offer? > Looking more closely at GIL is on my todo list, but it is a really long list. Without a closer look, I would guess that what I was doing was more bassed on a abstract base class model of an image, and GIL is template based. The interface class I was using has interesting things like BeginAccess(region) ... EndAccess() for accessing the pixels. The EndAccess was particularly interesting because you could then chain actions to the end of the write (ie update the UI in the case of an image widget, or use this image as the middle layer of a 3 layer composite in a paint program, with the composite result image chained to an action that updated part of the UI, etc). >> The import/export procs will eventually need to handle options. Do >> you expect the import/export procs to bring up UI, or should you pass >> in a dictionary_t of params to the export funcs, or something like that? > > > This is a good question. I'd expect the functions to be able to run > without user intervention (so scripting parameters should be able to be > passed), but the possibility of popping a UI to detail further command > parameters is not out of the question. I'll have to think a bit more > about this one. Incidentally we have recently released a modal dialog > interface API that accomplishes this very task pretty handily, so > leveraging that might be good. > 'leveraging' but not depending on, right? :-) >> Tony Van Eerd >> Adobe Waterloo >> -via Thunderbird- >> >> Foster T. Brereton wrote: >> >>> All, >>> Ralph Thomas and I have begun designing a picture widget for ASL. >>> This widget will cover icons in a generic way as well. The in- >>> development design is posted at: >>> <http://opensource.adobe.com/twiki/bin/view/AdobeSource/ >>> PictureView> >>> We would welcome any commentary, feedback, and/or refinement on the >>> design or the documentation. If anyone would like to contribute >>> please provide it either by email to the ASL mailing list or on the >>> Wiki page directly. If you do not have write access to the Wiki >>> page yet please create a Wiki account; once that is done email me >>> and I will authorize you. >>> Thanks in advance for any time you can give to the effort. >>> Blessings, >>> Foster >>> -- >>> Foster T. Brereton <}}}>< Romans 3:21-26 >>> A d o b e S o f t w a r e T e c h n o l o g y L a b >>> "What 99 percent of programmers need to know is not how to build >>> components but how to use them." -- Alexander Stepanov > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > |
|
From: Lubomir B. <lbo...@ad...> - 2006-02-15 00:46:50
|
Foster,
=20
My recommendation is that the image IO be written as a GIL extension =
module.
We already have a GIL extension to load/save images (JPEG and TIFF files =
are currently supported).
Hailin is interested in us pushing towards releasing the extension.
It is currently not in ASL for these reasons:
=20
1. The code needs to be reviewed
2. Only the common color spaces and channel depths are supported (some =
uncommon JPEG and TIFF files may fail to load)
3. There is a dependency to libjpeg and libtiff. I was reluctant to =
having .lib files as part of GIL, due to the platforms and compile =
setting combinations we need to provide and maintain.
4. I am unsure about the licensing terms of the above mentioned =
libraries.
=20
You can find the GIL I/O extension on boxer:1770 here:
//gil/extension/io/
=20
And the libs are here:
=20
//gil/lib/libjpeg/=20
//gil/lib/libtiff/
=20
Lubomir
=20
________________________________
From: own...@ad... on behalf of Foster T. Brereton
Sent: Tue 2/14/2006 4:06 PM
To: ASL External; ASL Users
Subject: asl-users: Request for Comments: ASL Picture Widget
All,
Ralph Thomas and I have begun designing a picture widget for ASL.=20
This widget will cover icons in a generic way as well. The in-
development design is posted at:
=
<http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView>
We would welcome any commentary, feedback, and/or refinement on the=20
design or the documentation. If anyone would like to contribute=20
please provide it either by email to the ASL mailing list or on the=20
Wiki page directly. If you do not have write access to the Wiki page=20
yet please create a Wiki account; once that is done email me and I=20
will authorize you.
Thanks in advance for any time you can give to the effort.
Blessings,
Foster
--
Foster T. Brereton <}}}>< Romans 3:21-26
A d o b e S o f t w a r e T e c h n o l o g y L a b
"What 99 percent of programmers need to know is not how to build=20
components but how to use them." -- Alexander Stepanov
|
|
From: Ralph T. <ra...@gm...> - 2006-02-16 01:59:16
|
libjpeg is listed as "freely distributable" on freshmeat (and I did the research previously and came to the same conclusion). I can probably easily rustle up an image_factory_t implementation for PNG files as I already have some imageio code that uses libpng for storing thumbnail previews. libjpeg, libpng and libtiff could be included like boost is currently (in the third_party directory), meaning that ASL users would have to get the sources themselves if they wanted to use that imageio extension. Ralph On 2/14/06, Lubomir Bourdev <lbo...@ad...> wrote: > Foster, > > My recommendation is that the image IO be written as a GIL extension modu= le. > We already have a GIL extension to load/save images (JPEG and TIFF files = are currently supported). > Hailin is interested in us pushing towards releasing the extension. > It is currently not in ASL for these reasons: > > 1. The code needs to be reviewed > 2. Only the common color spaces and channel depths are supported (some un= common JPEG and TIFF files may fail to load) > 3. There is a dependency to libjpeg and libtiff. I was reluctant to havin= g .lib files as part of GIL, due to the platforms and compile setting combi= nations we need to provide and maintain. > 4. I am unsure about the licensing terms of the above mentioned libraries= . > > You can find the GIL I/O extension on boxer:1770 here: > //gil/extension/io/ > > And the libs are here: > > //gil/lib/libjpeg/ > //gil/lib/libtiff/ > > Lubomir > > > ________________________________ > > From: own...@ad... on behalf of Foster T. Brereton > Sent: Tue 2/14/2006 4:06 PM > To: ASL External; ASL Users > Subject: asl-users: Request for Comments: ASL Picture Widget > > > > All, > > Ralph Thomas and I have begun designing a picture widget for ASL. > This widget will cover icons in a generic way as well. The in- > development design is posted at: > > <http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureVi= ew> > > We would welcome any commentary, feedback, and/or refinement on the > design or the documentation. If anyone would like to contribute > please provide it either by email to the ASL mailing list or on the > Wiki page directly. If you do not have write access to the Wiki page > yet please create a Wiki account; once that is done email me and I > will authorize you. > > Thanks in advance for any time you can give to the effort. > > Blessings, > Foster > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: Sean P. <sp...@ad...> - 2006-02-15 02:43:21
|
The semantic description is a bit at odds with itself and with the API - First - what is this? If it is a visual label (like a static_text) - then the API is pretty good except there shouldn't be a "hit proc" - there should _never_ be a hit proc. This is either a label (a purely visual element like a static text) - a button, or a view. Not one picture to rule them all. If this is to be only a label, perhaps it should be combined with static_text under a new "label" widget - the binding to the image through Eve might be an href in the label (hmmm, maybe that's over kill) - and an alternate constructor on the label_t widget. If it is a button - mostly the same comments as above except it should be part of button_t. If it is an image view (this would be the most ambitious widget) - then it should bind to an image view. The widget should support at least pan and zoom (these controls wouldn't need to be bind-able - but allow them to be bound would let you attach them to the basic sheet to preserve view state). I can envision all kinds of nice UI's for this (transparent overlay that comes up when you mouse over...) - could be slick - we can attempt to work with a UI designer to design the _last_ preview widget... If there is a monitor function - that would imply an image editor... perhaps a bit too ambitious for the first cut. Sean On Feb 14, 2006, at 4:06 PM, Foster T. Brereton wrote: > All, > > Ralph Thomas and I have begun designing a picture widget for ASL. > This widget will cover icons in a generic way as well. The in- > development design is posted at: > > <http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView> > > We would welcome any commentary, feedback, and/or refinement on the > design or the documentation. If anyone would like to contribute > please provide it either by email to the ASL mailing list or on the > Wiki page directly. If you do not have write access to the Wiki > page yet please create a Wiki account; once that is done email me > and I will authorize you. > > Thanks in advance for any time you can give to the effort. > > Blessings, > Foster > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > |
|
From: Foster T. B. <fbr...@ad...> - 2006-02-15 17:24:45
|
On Feb 14, 2006, at 06:43p, Sean Parent wrote: > First - what is this? If it is a visual label (like a static_text) > - then the API is pretty good except there shouldn't be a "hit > proc" - there should _never_ be a hit proc. This is either a label > (a purely visual element like a static text) - a button, or a view. > Not one picture to rule them all. If this is to be only a label, > perhaps it should be combined with static_text under a new "label" > widget - the binding to the image through Eve might be an href in > the label (hmmm, maybe that's over kill) - and an alternate > constructor on the label_t widget. This widget isn't intended to be an uber-implementation for all general use cases of an image within an application. The hit test proc, if anything, would simply be a void function or perhaps return modifier keys. In either instance, I got the idea from static_text_t, which, although it is a label, it too has a hit proc. The hit proc for the static_text, when used, sets the focus of the keyboard to the edit_text (or other widget) that that label decorates. Perhaps this shouldn't be a public API, intended only for internal use within the implementation: if that is the case I can file a bug to have it removed. In that case, too, the public hit API for the picture widget would also vanish. I was shooting for semantic consistency across all things "label". > If it is a button - mostly the same comments as above except it > should be part of button_t. I never had any intention of making it behave as if it were a button. It isn't intended to latch out to a command in any way. > If it is an image view (this would be the most ambitious widget) - > then it should bind to an image view. The widget should support at > least pan and zoom (these controls wouldn't need to be bind-able - > but allow them to be bound would let you attach them to the basic > sheet to preserve view state). I can envision all kinds of nice > UI's for this (transparent overlay that comes up when you mouse > over...) - could be slick - we can attempt to work with a UI > designer to design the _last_ preview widget... This was the foundation upon which we began when coming up with the design of the picture widget. I have no qualms about starting simple and working our way up. The reason I began thinking about the picture widget implementation is because I need icon support -- if we started there and worked our way forward, I would think it would be a good way to do it. Blessings, Foster -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Sean P. <sp...@ad...> - 2006-02-15 18:40:24
|
On Feb 15, 2006, at 9:24 AM, Foster T. Brereton wrote: > On Feb 14, 2006, at 06:43p, Sean Parent wrote: > >> First - what is this? If it is a visual label (like a static_text) >> - then the API is pretty good except there shouldn't be a "hit >> proc" - there should _never_ be a hit proc. This is either a label >> (a purely visual element like a static text) - a button, or a >> view. Not one picture to rule them all. If this is to be only a >> label, perhaps it should be combined with static_text under a new >> "label" widget - the binding to the image through Eve might be an >> href in the label (hmmm, maybe that's over kill) - and an >> alternate constructor on the label_t widget. > > This widget isn't intended to be an uber-implementation for all > general use cases of an image within an application. The hit test > proc, if anything, would simply be a void function or perhaps > return modifier keys. In either instance, I got the idea from > static_text_t, which, although it is a label, it too has a hit > proc. The hit proc for the static_text, when used, sets the focus > of the keyboard to the edit_text (or other widget) that that label > decorates. static_text should not have a public hit proc. This is exposing an implementation detail of edit_text through static text. Ideally, event handling would be done by registering geometry with an event dispatcher, not by assuming that something will call through a widget. This should be removed or at least be made private to the platform implementation of edit_text. > Perhaps this shouldn't be a public API, intended only for internal > use within the implementation: if that is the case I can file a bug > to have it removed. In that case, too, the public hit API for the > picture widget would also vanish. I was shooting for semantic > consistency across all things "label". That would be good - static_text as a name has always bugged me as it really is just a decoration - it is neither a view or controller for anything (although it could be a view of external text in the future, but then it wouldn't be "static" - and we haven't gone there yet). For what you are describing I would create a new widget type, called "label" or "decoration" or something like that and group the current static text and this static picture into it. Specifying the image through the Eve interface to this should be with a URL - consider that in the design for the factory. > >> If it is a button - mostly the same comments as above except it >> should be part of button_t. > > I never had any intention of making it behave as if it were a > button. It isn't intended to latch out to a command in any way. > >> If it is an image view (this would be the most ambitious widget) - >> then it should bind to an image view. The widget should support at >> least pan and zoom (these controls wouldn't need to be bind-able - >> but allow them to be bound would let you attach them to the basic >> sheet to preserve view state). I can envision all kinds of nice >> UI's for this (transparent overlay that comes up when you mouse >> over...) - could be slick - we can attempt to work with a UI >> designer to design the _last_ preview widget... > > This was the foundation upon which we began when coming up with the > design of the picture widget. I have no qualms about starting > simple and working our way up. The reason I began thinking about > the picture widget implementation is because I need icon support -- > if we started there and worked our way forward, I would think it > would be a good way to do it. No disagreement here. > > Blessings, > Foster > > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > |
|
From: Ralph T. <ra...@gm...> - 2006-02-15 20:53:06
|
On 2/15/06, Sean Parent <sp...@ad...> wrote: > Specifying the image through the Eve interface to this should be with > a URL - consider that in the design for the factory. Ideally what kind of URLs would you want to support? Obviously "file://" and perhaps "resource://" (for getting data from MacOS bundle, or directly from the executable's resource section on Windows). Ralph > > > >> If it is a button - mostly the same comments as above except it > >> should be part of button_t. > > > > I never had any intention of making it behave as if it were a > > button. It isn't intended to latch out to a command in any way. > > > >> If it is an image view (this would be the most ambitious widget) - > >> then it should bind to an image view. The widget should support at > >> least pan and zoom (these controls wouldn't need to be bind-able - > >> but allow them to be bound would let you attach them to the basic > >> sheet to preserve view state). I can envision all kinds of nice > >> UI's for this (transparent overlay that comes up when you mouse > >> over...) - could be slick - we can attempt to work with a UI > >> designer to design the _last_ preview widget... > > > > This was the foundation upon which we began when coming up with the > > design of the picture widget. I have no qualms about starting > > simple and working our way up. The reason I began thinking about > > the picture widget implementation is because I need icon support -- > > if we started there and worked our way forward, I would think it > > would be a good way to do it. > > No disagreement here. > > > > > Blessings, > > Foster > > > > > > -- > > Foster T. Brereton <}}}>< Romans 3:21-26 > > A d o b e S o f t w a r e T e c h n o l o g y L a b > > "What 99 percent of programmers need to know is not how to build > > components but how to use them." -- Alexander Stepanov > > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X