Menu
▾
▴
adobe-source-devel — ASL development topic discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(70) |
Apr
(101) |
May
(24) |
Jun
(15) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(5) |
Nov
(5) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(58) |
Feb
(29) |
Mar
(4) |
Apr
(5) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(6) |
Sep
(32) |
Oct
(29) |
Nov
(7) |
Dec
(8) |
| 2007 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(19) |
May
(26) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(24) |
Apr
(8) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
(1) |
May
(52) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
(4) |
| 2010 |
Jan
(2) |
Feb
(6) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(3) |
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Foster T. B. <fbr...@ad...> - 2005-03-28 17:13:53
|
Yes. I'd like to make the standard character encoding inside the ASL to be UTF8. There isn't any internationalization support currently in the application, but UTF8 is the wisest choice for the internal format. Your UXTHEME work sounds very impressive! I am interested to take a look at it when you think it's ready. Blessings, Foster ----- Original Message ----- From: "Ralph Thomas" <ra...@gm...> To: "Foster T. Brereton" <fbr...@ad...> Sent: Friday, March 25, 2005 5:13 PM Subject: Re: [Adobe-source-devel] Win32: ui-core fonts and fudges > So is it okay to standardize on UTF-8 in ui-core? By this I mean that > we assume that all strings going in and coming out of ui-core are in > UTF-8. This is very easy to do on Win32 (with WideCharToMultiByte and > friends) and MacOS (CFString supports UTF-8 as an encoding). > > UTF-8 could easily be put into the Eve/Adam files (although I guess > some care would have to be taken to correctly escape "). It has the > additional advantage of containing US-ASCII without any special > characters (so existing Eve/Adam files won't create illegible GUI). > > Thanks! > Ralph > > > On Fri, 25 Mar 2005 09:14:50 -0800, Foster T. Brereton > <fbr...@ad...> wrote: >> Intriguing! Please keep us posted. >> >> A lot of the code in Win32 is from an older project. If there are newer >> and better means of managing these UI elements I'm all for it. >> >> Blessings, >> Foster >> >> On Mar 24, 2005, at 11:07p, Ralph Thomas wrote: >> >> > Hi all, >> > >> > I've been reading through the Win32 ui-core code. I have two questions: >> > >> > 1. Why is the font name hard-coded? Shouldn't DEFAULT_GUI_FONT be >> > used? >> > 2. How does i18n work? It looks like text is always in the current >> > codepage (i.e.: not UTF-X). >> > >> > Also, I've been playing with the UXTHEME bits, and am working to >> > remove the fudges. I'm planning on doing this in such a way that when >> > UXTHEME is available (i.e.: on Windows XP and 2003) it will be used to >> > look up metrics, and when it's not available the values will be >> > calculated and fudged with constants. The UXTHEME font bits can also >> > tell you about baselines inside widgets (I think -- I haven't tested >> > it yet). >> > >> > I'm quite sure that the widget metrics can change on the fly. If you >> > open Control Panel -> Accessibility -> Display Options, and enable >> > high-contrast mode then the sizes of various standard widgets change. >> > Windows does this by sending a WM_THEMECHANGED message to all windows >> > (and stock widgets know what to do, owner drawn need to capture the >> > message). >> > >> > I'll keep you updated on my UXTHEME research :). >> > >> > Thanks, >> > Ralph >> >> -- >> 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...> - 2005-03-25 18:00:28
|
Hey Peter, I did this yesterday, and sent out an email announcing its arrival. The =20= name of the list is adobe-source-commits, as adobe-source-cvs and =20 adobe-source-commit would not have been archived automatically by =20 SourceForge. It would be best for all contributors to be subscribed to =20= this list. Blessings, Foster On Mar 25, 2005, at 09:52a, Peter K=FCmmel wrote: > Hi Foster, > > here a suggestion for getting informed of cvs repositorys changes: > > Why do you not set up mailing list for cvs messages, > > e.g. ado...@li..., > > which sends a message if something has changed in the > repository and includes a diff of changes. > > With subscribing such a list it's easy to be up to date. > > See sf doc: > http://sourceforge.net/docman/display_doc.php?=20 > docid=3D772&group_id=3D1#mlcreate > > > Regards, > Peter > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real =20 > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- 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: <syn...@gm...> - 2005-03-25 17:52:22
|
Hi Foster, here a suggestion for getting informed of cvs repositorys changes: Why do you not set up mailing list for cvs messages, e.g. ado...@li..., which sends a message if something has changed in the repository and includes a diff of changes. With subscribing such a list it's easy to be up to date. See sf doc: http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#mlcreate Regards, Peter |
|
From: <syn...@gm...> - 2005-03-25 17:44:03
|
Foster T. Brereton wrote: >> In assemblage.cpp, line 28, changing this: >> adobe::for_each(connections_m, >> boost::bind(connection_t::disconnect, _1)); >> to this: >> adobe::for_each(connections_m, >> boost::bind(&connection_t::disconnect, _1)); >> fixes another compiler error. It's the same change I've posted in the 'mscv8/visual' mail > > From what I understand connection_t::disconnect and > &connection_t::disconnect are equivalent provided that > connection_t::disconnect is a member function, not a member variable. > The change shouldn't be necessary but if the compiler prefers the latter > over the former, so be it. Isn't the the difference that 'connection_t::disconnect' is just a type and '&connection_t::disconnect' is a pointer to a function with this type? The member function is generated by templates but finally you need a pointer to call it, or I'm wrong? Regards, Peter |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-25 17:11:42
|
All, On Mar 25, 2005, at 08:05a, David Catmull wrote: > I'm having a hard time figuring out this error. It happens on this > line in the bevel_button_proxy_t constructor (around line 1315 of > client_assembler.cpp): > control_m.add_menu_item( > (*iter).get<adobe::dictionary_t>()[key_name].get<std::string>(), > (*iter).get<adobe::dictionary_t>()[key_value]); > I'm getting "parse error before `>' token" and it seems to be > referring to <adobe::dictionary_t>. This is odd because dictionary_t > is used several times before this in this file. > For these errors, try adding a 'template' keyword in front of the call to get: (*iter).template get<adobe::dictionary> ... [key_name].template get<std::string>(), etc., etc. Addition of the keyword is a permissible C++ "hint" to compilers that get is a templated function. The reason why this can't necessarily be figured out by the compiler eludes me at this point. Let me know if that helps. > In assemblage.cpp, line 28, changing this: > adobe::for_each(connections_m, boost::bind(connection_t::disconnect, > _1)); > to this: > adobe::for_each(connections_m, boost::bind(&connection_t::disconnect, > _1)); > fixes another compiler error. From what I understand connection_t::disconnect and &connection_t::disconnect are equivalent provided that connection_t::disconnect is a member function, not a member variable. The change shouldn't be necessary but if the compiler prefers the latter over the former, so be 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: David C. <unc...@un...> - 2005-03-25 16:05:59
|
I'm having a hard time figuring out this error. It happens on this line in the bevel_button_proxy_t constructor (around line 1315 of client_assembler.cpp): control_m.add_menu_item( (*iter).get<adobe::dictionary_t>()[key_name].get<std::string>(), (*iter).get<adobe::dictionary_t>()[key_value]); I'm getting "parse error before `>' token" and it seems to be referring to <adobe::dictionary_t>. This is odd because dictionary_t is used several times before this in this file. In assemblage.cpp, line 28, changing this: adobe::for_each(connections_m, boost::bind(connection_t::disconnect, _1)); to this: adobe::for_each(connections_m, boost::bind(&connection_t::disconnect, _1)); fixes another compiler error. I haven't yet figured out the "parse error before `;' token" error at assemblage.hpp line 48. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-03-25 07:07:36
|
Hi all, I've been reading through the Win32 ui-core code. I have two questions: 1. Why is the font name hard-coded? Shouldn't DEFAULT_GUI_FONT be used? 2. How does i18n work? It looks like text is always in the current codepage (i.e.: not UTF-X). Also, I've been playing with the UXTHEME bits, and am working to remove the fudges. I'm planning on doing this in such a way that when UXTHEME is available (i.e.: on Windows XP and 2003) it will be used to look up metrics, and when it's not available the values will be calculated and fudged with constants. The UXTHEME font bits can also tell you about baselines inside widgets (I think -- I haven't tested it yet). I'm quite sure that the widget metrics can change on the fly. If you open Control Panel -> Accessibility -> Display Options, and enable high-contrast mode then the sizes of various standard widgets change. Windows does this by sending a WM_THEMECHANGED message to all windows (and stock widgets know what to do, owner drawn need to capture the message). I'll keep you updated on my UXTHEME research :). Thanks, Ralph |
|
From: Sean P. <sp...@ad...> - 2005-03-25 06:55:38
|
On Mar 24, 2005, at 9:02 AM, David Catmull wrote: > I've been thinking about the best way to imitate the OS X prefs dialog > layout in Eve, as seen here: > http://developer.apple.com/documentation/UserExperience/Conceptual/ > OSXHIGuidelines/XHIGLayout/chapter_11_section_2.html#//apple_ref/doc/ > uid/TP30000360/CHDEACGD > > Maybe there can be a different approach: let the "group box" be a more > general concept - a bunch of controls with a label - with different > possible representations (see the Grouping Controls page of the AHIG): > * The two-column "preferences" layout > * A regular group box control - ie an actual box with a label above it > * A text label above an indented set of controls, with (optionally?) a > separator line filling up the rest of the horizontal space after the > label > > The two-column layout may be less normal on Windows, so perhaps a > different layout could be used there. It's an interesting idea to make these be a variant of a group box - to get the labels to line up I think will require a fix in Eve2 (I don't think guides on containers do anything... but they should and did in Eve1, I'll have a look). Sean > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
|
From: David C. <unc...@un...> - 2005-03-25 04:22:52
|
On Mar 24, 2005, at 6:21 PM, Ralph Thomas wrote: > My program uses a splitter widget (a container which has two child > widgets and allows the user to resize the children by dragging the > splitter). I was wondering how best to implement a splitter container > using ASL? I've thought about this too. A splitter is a common enough element that I think it ought to be a standard Eve widget. I would have the two split panes explicitly in the .eve file. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-03-25 02:21:28
|
Hi folks, My program uses a splitter widget (a container which has two child widgets and allows the user to resize the children by dragging the splitter). I was wondering how best to implement a splitter container using ASL? Should I somehow tell Eve not to worry about the direct children of the splitter, or should I get the splitter to somehow communicate with Eve the sizes and locations of the children (and rely on Eve to resize the children). It seems like I could just not tell Eve about the splitter's children -- but what if the splitter's children are rows or columns which need to have sizes calculated by Eve (rather than a single widget)? Thanks, Ralph |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-24 18:54:00
|
Hey all, I have added the adobe-source-commits mailing list which will notify everyone subscribed of CVS repository changes. Please feel free to subscribe. 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...> - 2005-03-24 18:10:56
|
Yeah, for now this should move to be public. Blessings, Foster On Mar 23, 2005, at 11:45p, Ralph Thomas wrote: >> headers/mac/ui_core_implementation.hpp:168: error: `struct >> adobe::window_t::implementation_t' is private > > This one is a bit odd -- implementation_t is public for every other > widget in ui_core, except window_t where it's private except when > BOOST_MSVC is defined. Is there any motivation for keeping it private > for any build? I don't think that anything will break on Metrowerks if > it's public, right? > > Ralph > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon > 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. > Register > by 3/29 & save $300 > http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- 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...> - 2005-03-24 18:08:44
|
All, ADOBE_SERIALIZATION is a flag we us to turn on/off all uses of operator << in the ASL. Something you'd be able to do with it on would be: adobe::value_t foo(5); std::cout << foo << std::endl; // prints out 5 There are also some iostream manipulators (iomanip and all the related sources) that are used in Adobe Begin to get pdf-like output when the user hits the OK button (on Mac, anyways). The reason there is a switch is because we are not convinced the code is quite ready for full inclusion into the ASL, however it provides enough useful functionality for Adobe Begin that we didn't want to pull it all together. asl_lib_dev is the "development" version of the ASL. It is intended for use when clients are developing their application, giving them features they might find helpful in debugging their code. asl_lib is the "release" version of ASL, and the one we recommend final binaries be linking to. A question was raised a while back that we should just have one project with four targets, but decided against it as we wanted to keep serialization as completely separate as possible. To test this, Adobe Begin has four built targets: debug, release, debug (dev) and release (dev). The release targets are highly optimized, and the (dev) targets are linking to asl_lib_dev and have serialization set. I hope this clears some things up. Blessings, Foster On Mar 23, 2005, at 07:59p, David Catmull wrote: > On Mar 23, 2005, at 6:34 PM, Ralph Thomas wrote: >> (the asl_lib_dev has >> ADOBE_SERIALIZED defined for all objects, but asl_lib does not) > > I'm not quite clear on the significance of this, and why there are two > separate libraries. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon > 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. > Register > by 3/29 & save $300 > http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- 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: David C. <unc...@un...> - 2005-03-24 17:02:25
|
I've been thinking about the best way to imitate the OS X prefs dialog layout in Eve, as seen here: http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGLayout/chapter_11_section_2.html#//apple_ref/doc/ uid/TP30000360/CHDEACGD Maybe there can be a different approach: let the "group box" be a more general concept - a bunch of controls with a label - with different possible representations (see the Grouping Controls page of the AHIG): * The two-column "preferences" layout * A regular group box control - ie an actual box with a label above it * A text label above an indented set of controls, with (optionally?) a separator line filling up the rest of the horizontal space after the label The two-column layout may be less normal on Windows, so perhaps a different layout could be used there. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-03-24 07:45:08
|
> headers/mac/ui_core_implementation.hpp:168: error: `struct > adobe::window_t::implementation_t' is private This one is a bit odd -- implementation_t is public for every other widget in ui_core, except window_t where it's private except when BOOST_MSVC is defined. Is there any motivation for keeping it private for any build? I don't think that anything will break on Metrowerks if it's public, right? Ralph |
|
From: Ralph T. <ra...@gm...> - 2005-03-24 06:25:23
|
This was what the original build system did. The asl_lib_dev supports serialization, asl_lib does not (and requires some extra sources and is a bit bigger). I don't know if both are required, but personally I think they are -- in my other project (where I am currently evaluating ASL) I have no use for serialization and I'm targetting a really small machine. To get serialization ADOBE_SERIALIZED must be defined at build time (which is why the same compiled objects can't be used in both libraries -- they must be recompiled for each). Thanks, Ralph David Catmull <unc...@un...> wrote: > On Mar 23, 2005, at 6:34 PM, Ralph Thomas wrote: > > (the asl_lib_dev has > > ADOBE_SERIALIZED defined for all objects, but asl_lib does not) > > I'm not quite clear on the significance of this, and why there are two > separate libraries. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: David C. <unc...@un...> - 2005-03-24 03:59:32
|
Here are some more issues.
In ui_core_implementation.hpp, there are a bunch of warnings about
"specializing 'struct adobe::delete_ptr<something>' in a different
namespace". It looks like all those specialization macros ought to be
in a namespace adobe {} block.
Other errors:
client_assembler.cpp:1314: error: parse error before `>' token
headers/mac/ui_core_implementation.hpp:168: error: `struct
adobe::window_t::implementation_t' is private
headers/mac/ui_core_implementation.hpp:674: error: within this context
ui_core_implementation.cpp:68: error: no matching function for call to
`adobe::auto_resource<const __CFString*, adobe::ptr_traits<const
__CFString*> >::auto_resource(adobe::auto_resource<const __CFString*,
adobe::ptr_traits<const __CFString*> >)'
adobe/test/visual/sources/mac/ui_core_implementation.cpp:4952: error:
specialization of ReturnType adobe::view_for_element(DisplayElement&)
[with ReturnType = OpaqueControlRef*, DisplayElement = adobe::window_t]
after instantiation
adobe/test/visual/sources/mac/ui_core_implementation.cpp:5062: error:
specialization of ReturnType adobe::view_for_element(DisplayElement&)
[with ReturnType = OpaqueControlRef*, DisplayElement =
adobe::static_text_t] after instantiation
There are lots of warnings about assigning float values to int
variables, and the like. Apparently gcc isn't as happy about those
implicit conversions as CodeWarrior. For example:
adobe/test/visual/sources/mac/ui_core_implementation.cpp:536: warning:
assignment to `short int' from `float'
Maybe the tracking loop (line 1160) should be a do-while loop, so
finding a useful initial MouseTrackingResult value wouldn't be an
issue:
adobe/test/visual/sources/mac/ui_core_implementation.cpp:1117: warning:
initialization of negative value `-1' to `MouseTrackingResult'
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: David C. <unc...@un...> - 2005-03-24 03:59:21
|
On Mar 23, 2005, at 6:34 PM, Ralph Thomas wrote: > (the asl_lib_dev has > ADOBE_SERIALIZED defined for all objects, but asl_lib does not) I'm not quite clear on the significance of this, and why there are two separate libraries. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-03-24 02:34:52
|
Hi everyone, I'm planning on checking some rewritten Jamfiles into the sandbox. I've made the following changes: - The visual and adam_tutorial and visual code links with asl_dev. - The boost code is built using the proper mechanism. - The libraries are delivered into adobe/build/bin/<compiler>/<variant> The consequences of these changes are: - Shorter Jamfiles in adam_tutorial and visual - The MSVC solution files (and metrowerks files in build/asl*) will move to build/bin/... - The project-root.jam and boost-build.jam files move to adobe-source/ (i.e.: the project root) I haven't yet got it to build both libraries (the asl_lib_dev has ADOBE_SERIALIZED defined for all objects, but asl_lib does not) yet, although I think I can write a little rule to make it easier. Once I've done this (and gotten approval for the consequences) I'll check the new Jamfiles into the sandbox. Thanks! Ralph |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-23 19:44:41
|
Hey all, I've just checked in <adobe/config.hpp> changes to the sandbox, allowing for the use of ADOBE_PLATFORM_WIN and ADOBE_PLATFORM_MAC instead of the plethora of #ifdefs we've been pushing into the code. Please note that these are not intended to discern the compiler on which the code is being built- only the target platform. 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...> - 2005-03-23 19:02:02
|
Ralph Thomas pointed me to corkscrew, which I had up and running in minutes and now have a hole poked in the firewall big enough that I can commit some changes to the sandbox. So that's what I did. I've improved the Win32 implemetation quite a bit: - I have checked in MSVC .sln files for the various libraries and visual so dependent libraries are built before Begin is, so you don't have to hunt down subprojects and build them before building Begin in MSVC anymore. - visual.exe (the binary created on Windows) now does *not* open a default dialog when executed. The editor window on Macintosh is something I'd like to build into the Windows code, but at this point because it's not working I didn't think piggybacking on the editor loading code was a wise idea. Now, to launch a dialog, you must drag-and-drop an adam and eve file pair on the executable to launch it. From the command line the files need to be the first and second argument to the app. - Many Win32 widgets were further fleshed out. Check out the image size dialog (and its subdialog)-- everything works now! There are some behavior issues left to implement (focus related issues, etc) and the basline alignment isn't working quite right yet (anyone know how to do this on Win32?) but the dialog is in a much better state than it was before. 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...> - 2005-03-23 18:23:08
|
I'd like to keep it in there for now. I anticipate it will serve a purpose in the (hopefully near) future, though for now it's just sitting there. I believe the only reference to it is in client_assembler.cpp. I'd make the change myself but I'm still wrestling with this ssh-through-the-firewall issue. Blessings, Foster On Mar 23, 2005, at 10:17a, Ralph Thomas wrote: > I noticed that this was only being included on GCC/Mac and I changed > it in the sandbox so that it would actually compile. It sounds like > we'd be better off just cvs delete ing the file altogether. > > Thanks, > Ralph > > On Wed, 23 Mar 2005 08:44:24 -0800, Foster T. Brereton > <fbr...@ad...> wrote: >> Interesting... I haven't seen this problem before, and am unsure as to >> why it's showing only in GCC on the Mac... >> >> Another nit: This header isn't being used currently. We were working >> on >> the semantics of a button and the notion of it controlling a latch >> fell >> out. This is where this header came from, but we haven't got the >> details worked out yet. References to this header file can be removed. >> >> Blessings, >> Foster >> >> On Mar 22, 2005, at 06:15p, David Catmull wrote: >> >>> I'm working on my XCode "Adobe Begin" project. After setting up the >>> header paths so it properly finds boost and so forth, I get these >>> errors: >>> >>> headers/report_exception.hpp:43: error: looser throw specifier for >>> `virtual adobe::implementation::os_exception::~os_exception()' >>> /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding >>> `virtual std::exception::~exception() throw ()' >>> headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does >>> not have any field named `trigger_func_m' >>> headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does >>> not have any field named `validity_func_m' >>> adobe/test/visual/sources/client_assembler.cpp:1314: error: parse >>> error before `>' token >>> >>> The throw specifier issue seems to be from the implicit destructor >>> for >>> os_exception. >>> >>> -- >>> David Catmull >>> unc...@un... >>> http://www.uncommonplace.com/ >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: 2005 Windows Mobile Application >>> Contest >>> Submit applications for Windows Mobile(tm)-based Pocket PCs or >>> Smartphones >>> for the chance to win $25,000 and application distribution. Enter >>> today at >>> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click >>> _______________________________________________ >>> Adobe-source-devel mailing list >>> Ado...@li... >>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel >>> >>> >> -- >> 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 Microsoft Mobile & Embedded DevCon >> 2005 >> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest >> Windows >> Embedded(r) & Windows Mobile(tm) platforms, applications & content. >> Register >> by 3/29 & save $300 >> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click >> _______________________________________________ >> Adobe-source-devel mailing list >> Ado...@li... >> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel >> > > -- 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...> - 2005-03-23 18:17:18
|
I noticed that this was only being included on GCC/Mac and I changed it in the sandbox so that it would actually compile. It sounds like we'd be better off just cvs delete ing the file altogether. Thanks, Ralph On Wed, 23 Mar 2005 08:44:24 -0800, Foster T. Brereton <fbr...@ad...> wrote: > Interesting... I haven't seen this problem before, and am unsure as to > why it's showing only in GCC on the Mac... > > Another nit: This header isn't being used currently. We were working on > the semantics of a button and the notion of it controlling a latch fell > out. This is where this header came from, but we haven't got the > details worked out yet. References to this header file can be removed. > > Blessings, > Foster > > On Mar 22, 2005, at 06:15p, David Catmull wrote: > > > I'm working on my XCode "Adobe Begin" project. After setting up the > > header paths so it properly finds boost and so forth, I get these > > errors: > > > > headers/report_exception.hpp:43: error: looser throw specifier for > > `virtual adobe::implementation::os_exception::~os_exception()' > > /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding > > `virtual std::exception::~exception() throw ()' > > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > > not have any field named `trigger_func_m' > > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > > not have any field named `validity_func_m' > > adobe/test/visual/sources/client_assembler.cpp:1314: error: parse > > error before `>' token > > > > The throw specifier issue seems to be from the implicit destructor for > > os_exception. > > > > -- > > David Catmull > > unc...@un... > > http://www.uncommonplace.com/ > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: 2005 Windows Mobile Application > > Contest > > Submit applications for Windows Mobile(tm)-based Pocket PCs or > > Smartphones > > for the chance to win $25,000 and application distribution. Enter > > today at > > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > > _______________________________________________ > > Adobe-source-devel mailing list > > Ado...@li... > > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > > > > -- > 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 Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-23 17:37:10
|
Hey all, I'm currently stuck behind Adobe's firewall, but am trying to find a way to get through it with CVS. In the meantime, does anyone have a suggestion? I need SSH access through and HTTP proxy, but CVS doesn't support it by default. I have a host of changes coming to Win32 which will be cool. I also am interested to look at the changes you all have made, too. There is also some platform detection code that I'd like to get submitted soon, so please be on the lookout for that. It'll allow you to #ifdef (ADOBE_PLATFORM_MACINTOSH), etc. 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...> - 2005-03-23 16:44:48
|
Interesting... I haven't seen this problem before, and am unsure as to why it's showing only in GCC on the Mac... Another nit: This header isn't being used currently. We were working on the semantics of a button and the notion of it controlling a latch fell out. This is where this header came from, but we haven't got the details worked out yet. References to this header file can be removed. Blessings, Foster On Mar 22, 2005, at 06:15p, David Catmull wrote: > I'm working on my XCode "Adobe Begin" project. After setting up the > header paths so it properly finds boost and so forth, I get these > errors: > > headers/report_exception.hpp:43: error: looser throw specifier for > `virtual adobe::implementation::os_exception::~os_exception()' > /usr/include/gcc/darwin/3.3/c++/exception:56: error: overriding > `virtual std::exception::~exception() throw ()' > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > not have any field named `trigger_func_m' > headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does > not have any field named `validity_func_m' > adobe/test/visual/sources/client_assembler.cpp:1314: error: parse > error before `>' token > > The throw specifier issue seems to be from the implicit destructor for > os_exception. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: 2005 Windows Mobile Application > Contest > Submit applications for Windows Mobile(tm)-based Pocket PCs or > Smartphones > for the chance to win $25,000 and application distribution. Enter > today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- 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 |
2 messages has been excluded from this view by a project administrator.
