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: David C. <unc...@un...> - 2005-04-11 19:03:06
|
On Apr 11, 2005, at 11:38 AM, Foster T. Brereton wrote: > Or would it make more sense to remove Command as a modifier option all > together? Does anyone else have any thoughts on the issue? Have you > run across this / solved it before? I think the question is, when is it important to use the command key? I'm inclined to say that anything that refers to the command key is inherently Mac-specific, so Windows code should just ignore it. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Foster T. B. <fbr...@ad...> - 2005-04-11 18:48:42
|
I think this is an interesting question -- another question that encompasses this would be how to build a library with multiple modules programmed under the ASL assemblage paradigm. My initial thoughts would be that you would want to figure out what the intention of the library would be, and export just the APIs from the internal modules and assembler code that comply with those semantics. For instance in the case below, you would want to have: - some parts of Adam (monitor_xxx) made available - some way of getting information about cells in the Adam sheet - some way of including non-ui_core widgets in the client_assembler pipeline - some way of folding the non-ui_core widgets into the event handling mechanism - more? In each of these cases, it would involve a nearly-direct one-to-one correspondence between the public API and a function in either one of the modules or the client assemblage code. This could effectively reduce Adobe Begin to be a basic frontend to some "dialog manager" library. What other thoughts do people have? Blessings, Foster On Apr 10, 2005, at 11:46p, Ralph Thomas wrote: > Hi everybody, > > What are the steps we need to take to turn the visual test into a > library? The things I want to be able to do with it are: > > * Load Adam and Eve files and have the relations between them linked > up. > * Register my own widget types, in addition to those provided by > ui-core. > * Register my own function callbacks, like @ok. > > Maybe (although certainly for custom widgets): > > * Bind callback functions to cells (to be informed about cell > changes). > > What other requirements are there for a visual library? > > Thanks! > Ralph > > ------------------------------------------------------- > 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 -- 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-04-11 18:38:25
|
Hey all, Currently we have several modifier keys on the Mac: - shift - caps lock - option - control - command On Windows, these map one-to-one except for the command key. For example on my IBM ThinkPad, there is no key that would do well to map to Command on the Mac. The only option I can think of right now is mapping Alt + Ctl = Cmd on Win32, however that opens up a whole new can of worms. Or would it make more sense to remove Command as a modifier option all together? Does anyone else have any thoughts on the issue? Have you run across this / solved it 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: Ralph T. <ra...@gm...> - 2005-04-11 17:23:55
|
Work is being done towards committing all of the changes here, and is being logged in this bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1180074&group_id=132417&atid=724218 Thanks, Ralph On Apr 10, 2005 9:06 AM, Tobias Schwinger <tsc...@ne...> wrote: > I accidently sent my reply to Ralph instead to the list - it was > actually intended to go here (especially because of that runtime issue > mentioned in the last paragraph): > > -------- Original Message -------- > > Ralph Thomas wrote: > > >On Apr 8, 2005 2:04 PM, Tobias Schwinger <tsc...@ne...> wrote: > > > > > >>All builds have been done via Boost.Jam and I had to tweak > >>"boost/thread/detail/config.hpp" for static linkage because the > >>BOOST_THREAD_DECL macro expands to an invalid DLL-import attribute (I > >>guess this has to do with Boost.Build V2 since I never had this problem > >>building Boost with V1. Does "proper mechanism" in the "new build > >>structure" thread refer to using Boost.Build V1 for the Boost libraries > >>? If so, this is probably already fixed in the Sandbox). > >> > >> > > > >We're still using Boost.Build V2, and I can't figure out how to make > >Boost.Thread build without changing it's Jamfile. The change which I > >have used is at the head of boost/libs/thread/build/Jamfile.v2 -- I > >add "<link>static:<define>BOOST_THREAD_USE_LIB=1" under the similar > >line for correctly making a DLL build. I don't know why Boost.Thread > >doesn't respect the static linking flag in > >sandbox/adobe-source/adobe/build -- all of the other boost libraries > >seem to. > > > > > > ... or "BOOST_THREAD_USE_DLL" is defined accidently and > "BOOST_THREAD_USE_LIB" is not considered by the config header beacause > of this. > > >On the plus side, Foster has done a good job at making sure that > >things build properly when using the *.vcproj files (with the IDE) -- > >unfortunately I don't think that the VC++ Toolbox comes with a tool to > >build from those. > > > > > > > >>All examples that can be built with MinGW work fine. The "visual" > >>example cannot be built, due to the lack of XP-Theme support in the > >>current MinGW distribution. However, I used 'uxtheme.h' (and "friends") > >>from the Platform-SDK in order to ensure everything compiles fine > >>(linking fails then). > >> > >> > > > >How does linking fail? I just removed the reference to uxtheme.lib > >from the Jamfile because uxtheme.dll is opened dynamically now (so > >that generated binaries run fine on Windows pre-XP). I'd really > >appreciate it if you could try again with the current sandbox. > > > > > > It did not compile OOTB (see attached patch, I also removed most > warnings while at it). > > Uxtheme dependencies are gone now. Further I had to adjust the Jamfile > so GCC sees something like "-lgdi32 -luser32..." when linking (or it > will find nothing at all). There was another problem with the Jamfile > regarding the generation of the resource header (just disabled it for > anything other than MSVC - probably the Boost.Build system does not know > about the MinGW resource compiler). > > After the CVS update the GCC-compiled examples fail with a "syntax error > exception". Please let me know in case there's anything I can do to > help (and what to look for) tracking this down. > > Regards, > > Tobias > > > Index: adobe-source/adobe/cmath.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/cmath.hpp,v > retrieving revision 1.2 > diff -u -r1.2 cmath.hpp > --- adobe-source/adobe/cmath.hpp 3 Apr 2005 00:29:55 -0000 1.2 > +++ adobe-source/adobe/cmath.hpp 9 Apr 2005 09:33:00 -0000 > @@ -33,7 +33,7 @@ > using std::round; > } // namespace adobe > > -#elif defined BOOST_MSVC > +#elif defined BOOST_MSVC || defined(__MINGW32__) > > namespace adobe { > typedef float float_t; > Index: adobe-source/adobe/eve.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/eve.hpp,v > retrieving revision 1.1 > diff -u -r1.1 eve.hpp > --- adobe-source/adobe/eve.hpp 19 Mar 2005 00:16:38 -0000 1.1 > +++ adobe-source/adobe/eve.hpp 9 Apr 2005 12:46:08 -0000 > @@ -146,10 +146,10 @@ > eve_t::alignment_t child_alignment_m; > }; > > - spacing_t spacing_m; > - boost::array<slice_t, 2> slice_m; > long indent_m; > bool create_m; > + spacing_t spacing_m; > + boost::array<slice_t, 2> slice_m; > > // containers only > eve_t::placement_t placement_m; > Index: adobe-source/adobe/istream.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/istream.hpp,v > retrieving revision 1.2 > diff -u -r1.2 istream.hpp > --- adobe-source/adobe/istream.hpp 24 Mar 2005 19:37:55 -0000 1.2 > +++ adobe-source/adobe/istream.hpp 9 Apr 2005 12:24:11 -0000 > @@ -41,14 +41,16 @@ > > const char* stream_name() const; > > - int line_number_m; // type int to match __LINE__ token > - std::streampos line_start_m; > - std::streampos position_m; > - > #if !defined(ADOBE_NO_DOCUMENTATION) > private: > name_t stream_name_m; > +public: > #endif // !defined(ADOBE_NO_DOCUMENTATION) > + > + int line_number_m; // type int to match __LINE__ token > + std::streampos line_start_m; > + std::streampos position_m; > + > }; > > class stream_error_t : public std::logic_error > Index: adobe-source/adobe/value.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/value.hpp,v > retrieving revision 1.1 > diff -u -r1.1 value.hpp > --- adobe-source/adobe/value.hpp 19 Mar 2005 00:16:38 -0000 1.1 > +++ adobe-source/adobe/value.hpp 9 Apr 2005 12:38:40 -0000 > @@ -169,7 +169,7 @@ > bool get(const value_t& value, T& x) const > { > if (value.type() != typeid(store_t)) return false; > - x = static_cast<value_t::instance<store_t>&>(*value.object_m).value_m; > + x = static_cast<T>(static_cast<value_t::instance<store_t>&>(*value.object_m).value_m); > return true; > } > > Index: adobe-source/adobe/future/assemblage.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/future/assemblage.hpp,v > retrieving revision 1.2 > diff -u -r1.2 assemblage.hpp > --- adobe-source/adobe/future/assemblage.hpp 30 Mar 2005 01:46:18 -0000 1.2 > +++ adobe-source/adobe/future/assemblage.hpp 9 Apr 2005 08:12:40 -0000 > @@ -12,6 +12,7 @@ > #include <list> > #include <vector> > > +#include <boost/bind.hpp> > #include <boost/signal.hpp> > #include <boost/function.hpp> > > Index: adobe-source/adobe/future/memory.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/future/memory.hpp,v > retrieving revision 1.2 > diff -u -r1.2 memory.hpp > --- adobe-source/adobe/future/memory.hpp 30 Mar 2005 17:15:54 -0000 1.2 > +++ adobe-source/adobe/future/memory.hpp 9 Apr 2005 09:27:11 -0000 > @@ -163,7 +163,8 @@ > template <typename lht> > static lht runtime_cast (std::auto_ptr<T>& x) > { > - lht::element_type* result = dynamic_cast<typename lht::element_type*>(x.get()); > + typedef typename lht::element_type* dest_type; > + dest_type result = dynamic_cast<dest_type>(x.get()); > if (result) x.release(); > return lht(result); > } > @@ -181,7 +182,8 @@ > template <typename lht> > static lht runtime_cast (adobe::auto_ptr<T, Traits>& x) > { > - lht::element_type* result = dynamic_cast<typename lht::element_type*>(x.get()); > + typedef typename lht::element_type* dest_type; > + dest_type result = dynamic_cast<typename lht::element_type>(x.get()); > if (result) x.release(); > return lht(result); > } > @@ -199,7 +201,8 @@ > template <typename lht> > static lht runtime_cast (adobe::auto_resource<T, Traits>& x) > { > - lht::element_type* result = dynamic_cast<typename lht::element_type*>(x.get()); > + typedef typename lht::element_type* dest_type; > + dest_type result = dynamic_cast<dest_type>(x.get()); > if (result) x.release(); > return lht(result); > } > @@ -263,10 +266,10 @@ > explicit auto_resource(pointer_type p = 0) throw(); > > auto_resource(auto_resource&) throw(); > - template <typename Y> auto_resource(auto_resource<Y, typename traits_type::rebind<Y>::other>&) throw(); > + template <typename Y> auto_resource(auto_resource<Y, typename traits_type::template rebind<Y>::other>&) throw(); > > auto_resource& operator = (auto_resource&) throw(); > - template<typename Y> auto_resource& operator = (auto_resource<Y, typename traits_type::rebind<Y>::other>&) throw(); > + template<typename Y> auto_resource& operator = (auto_resource<Y, typename traits_type::template rebind<Y>::other>&) throw(); > > ~auto_resource() throw(); > > @@ -282,8 +285,8 @@ > // 20.4.5.3 conversions: > auto_resource(auto_resource_ref<X, Traits>) throw(); > auto_resource& operator = (auto_resource_ref<X, Traits>) throw(); // addition > - template<typename Y> operator auto_resource_ref<Y, typename traits_type::rebind<Y>::other>() throw(); > - template<typename Y> operator auto_resource<Y, typename traits_type::rebind<Y>::other>() throw(); > + template<typename Y> operator auto_resource_ref<Y, typename traits_type::template rebind<Y>::other>() throw(); > + template<typename Y> operator auto_resource<Y, typename traits_type::template rebind<Y>::other>() throw(); > > // Peter Dimov's safe_bool conversion > operator safe_bool () const throw() > @@ -366,15 +369,15 @@ > typedef Traits traits_type; > typedef typename traits_type::element_type element_type; > typedef typename traits_type::pointer_type pointer_type; > - typedef typename inherited::auto_resource_ref<X*, Traits> auto_resource_ref_type; > + typedef typename inherited::template auto_resource_ref<X*, Traits> auto_resource_ref_type; > // 20.4.5.1 construct/copy/destroy: > explicit auto_ptr(pointer_type p = 0) throw(); > > auto_ptr(auto_ptr& r) throw(); > - template <typename Y> auto_ptr(auto_ptr<Y, typename traits_type::rebind<Y*>::other>& r) throw(); > + template <typename Y> auto_ptr(auto_ptr<Y, typename traits_type::template rebind<Y*>::other>& r) throw(); > > auto_ptr& operator = (auto_ptr&) throw(); > - template<typename Y> auto_ptr& operator = (auto_ptr<Y, typename traits_type::rebind<Y*>::other>&) throw(); > + template<typename Y> auto_ptr& operator = (auto_ptr<Y, typename traits_type::template rebind<Y*>::other>&) throw(); > > // construction and assignment from NULL > auto_ptr(clear_type*) throw(); > @@ -395,7 +398,7 @@ > // 20.4.5.3 conversions: > auto_ptr(auto_resource_ref_type r) throw(); > auto_ptr& operator = (auto_resource_ref_type) throw(); // addition > - template<typename Y> operator auto_ptr<Y, typename traits_type::rebind<Y*>::other>() throw(); > + template<typename Y> operator auto_ptr<Y, typename traits_type::template rebind<Y*>::other>() throw(); > }; > > /*************************************************************************************************/ > @@ -421,7 +424,7 @@ > > template <typename X, class Traits> > template <typename Y> > -inline auto_resource <X, Traits>::auto_resource(auto_resource<Y, typename traits_type::rebind<Y>::other>& x) throw() : > +inline auto_resource <X, Traits>::auto_resource(auto_resource<Y, typename traits_type::template rebind<Y>::other>& x) throw() : > pointer_m(x.release()) > { } > > @@ -435,7 +438,7 @@ > template <typename X, class Traits> > template <typename Y> > inline auto_resource<X, Traits>& auto_resource<X, Traits>::operator = ( > - auto_resource<Y, typename traits_type::rebind<Y>::other>& x) throw() > + auto_resource<Y, typename traits_type::template rebind<Y>::other>& x) throw() > { > reset(x.release()); > return *this; > @@ -502,18 +505,18 @@ > > template <typename X, class Traits> > template<typename Y> > -inline auto_resource<X, Traits>::operator typename auto_resource<X, Traits>::auto_resource_ref<Y, typename Traits::rebind<Y>::other>() throw() > +inline auto_resource<X, Traits>::operator typename auto_resource<X, Traits>::template auto_resource_ref<Y, typename Traits::template rebind<Y>::other>() throw() > { > - auto_resource_ref<Y, typename traits_type::rebind<Y>::other> r; > + auto_resource_ref<Y, typename traits_type::template rebind<Y>::other> r; > r.pointer_m = release(); > return r; > } > > template <typename X, class Traits> > template<typename Y> > -inline auto_resource<X, Traits>::operator auto_resource<Y, typename Traits::rebind<Y>::other>() throw() > +inline auto_resource<X, Traits>::operator auto_resource<Y, typename Traits::template rebind<Y>::other>() throw() > { > - return auto_resource<Y, typename traits_type::rebind<Y>::other>(release()); > + return auto_resource<Y, typename traits_type::template rebind<Y>::other>(release()); > } > > /*************************************************************************************************/ > @@ -555,7 +558,7 @@ > > template <typename X, class Traits> > template <typename Y> > -inline auto_ptr<X, Traits>::auto_ptr(auto_ptr<Y, typename traits_type::rebind<Y*>::other>& r) throw() : > +inline auto_ptr<X, Traits>::auto_ptr(auto_ptr<Y, typename traits_type::template rebind<Y*>::other>& r) throw() : > inherited(r) > { } > > @@ -569,7 +572,7 @@ > template <typename X, class Traits> > template<typename Y> > inline auto_ptr<X, Traits>& auto_ptr<X, Traits>::operator = ( > - auto_ptr<Y, typename traits_type::rebind<Y*>::other>& r) throw() > + auto_ptr<Y, typename traits_type::template rebind<Y*>::other>& r) throw() > { > inherited::operator = (r); > return *this; > @@ -660,9 +663,9 @@ > > template <typename X, class Traits> > template<typename Y> > -inline auto_ptr<X, Traits>::operator auto_ptr<Y, typename Traits::rebind<Y*>::other>() throw() > +inline auto_ptr<X, Traits>::operator auto_ptr<Y, typename Traits::template rebind<Y*>::other>() throw() > { > - return auto_ptr<Y, typename Traits::rebind<Y*>::other>(inherited::release()); > + return auto_ptr<Y, typename Traits::template rebind<Y*>::other>(inherited::release()); > } > > /*************************************************************************************************/ > Index: adobe-source/adobe/source/eve.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/source/eve.cpp,v > retrieving revision 1.5 > diff -u -r1.5 eve.cpp > --- adobe-source/adobe/source/eve.cpp 4 Apr 2005 16:43:33 -0000 1.5 > +++ adobe-source/adobe/source/eve.cpp 9 Apr 2005 12:52:00 -0000 > @@ -142,8 +142,8 @@ > } > > private: > - adobe::eve_t::evaluate_options_t options_m; > slice_select_t select_m; > + adobe::eve_t::evaluate_options_t options_m; > }; > > /*************************************************************************************************/ > @@ -305,7 +305,7 @@ > for (adobe::array_t::const_iterator iter(spacing_array.begin()); iter != spacing_array.end(); > ++iter) > { > - *dest_iter = iter->get<long>(); > + *dest_iter = static_cast<long>(iter->get<long>()); > ++dest_iter; > } > } > @@ -901,8 +901,9 @@ > > --last; > > - const adobe::eve_t::calculate_data_t::slice_t& leading_gslice (first->geometry_m.slice_m[select]); > - const adobe::eve_t::calculate_data_t::slice_t& trailing_gslice (last->geometry_m.slice_m[select]); > + // currently unsused > + // const adobe::eve_t::calculate_data_t::slice_t& leading_gslice (first->geometry_m.slice_m[select]); > + // const adobe::eve_t::calculate_data_t::slice_t& trailing_gslice (last->geometry_m.slice_m[select]); > adobe::eve_t::place_data_t::slice_t& leading_pslice (first->place_m.slice_m[select]); > adobe::eve_t::place_data_t::slice_t& trailing_pslice (last->place_m.slice_m[select]); > > @@ -942,7 +943,8 @@ > > for (child_iterator iter (first); iter != last; ++iter) > { > - const eve_t::calculate_data_t::slice_t& iter_gslice(iter->geometry_m.slice_m[select]); > + // currently unused > + // const eve_t::calculate_data_t::slice_t& iter_gslice(iter->geometry_m.slice_m[select]); > eve_t::place_data_t::slice_t& iter_pslice(iter->place_m.slice_m[select]); > > leading_outset_position = std::min(leading_outset_position, > @@ -1203,7 +1205,8 @@ > > void eve_t::view_proxy_t::adjust_with(child_iterator first, child_iterator last, slice_select_t select) > { > - const eve_t::calculate_data_t::slice_t& gslice(geometry_m.slice_m[select]); > + // currently unused > + // const eve_t::calculate_data_t::slice_t& gslice(geometry_m.slice_m[select]); > eve_t::place_data_t::slice_t& pslice(place_m.slice_m[select]); > > // determine how many children we have. > @@ -1264,7 +1267,8 @@ > > void eve_t::view_proxy_t::adjust_cross(child_iterator first, child_iterator last, slice_select_t select) > { > - const eve_t::calculate_data_t::slice_t& gslice(geometry_m.slice_m[select]); > + // currently unsused > + // const eve_t::calculate_data_t::slice_t& gslice(geometry_m.slice_m[select]); > eve_t::place_data_t::slice_t& pslice(place_m.slice_m[select]); > > /* > @@ -1278,7 +1282,8 @@ > > for (child_iterator iter(first); iter != last; ++iter) > { > - const eve_t::calculate_data_t::slice_t& iter_gslice (iter->geometry_m.slice_m[select]); > + // currently unused > + // const eve_t::calculate_data_t::slice_t& iter_gslice (iter->geometry_m.slice_m[select]); > eve_t::place_data_t::slice_t& iter_pslice(iter->place_m.slice_m[select]); > > guide_count = std::max(guide_count, iter_pslice.guides_m.size()); > @@ -1541,10 +1546,10 @@ > /*************************************************************************************************/ > > eve_t::calculate_data_t::calculate_data_t() : > - placement_m(eve_t::place_leaf), > indent_m(0), > create_m(true), > - spacing_m(2, 0) > + spacing_m(2, 0), > + placement_m(eve_t::place_leaf) > { > spacing_m[1] = 10; /* REVISIT FIXED VALUE container_spacing */ > } > Index: adobe-source/adobe/source/virtual_machine.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/source/virtual_machine.cpp,v > retrieving revision 1.1 > diff -u -r1.1 virtual_machine.cpp > --- adobe-source/adobe/source/virtual_machine.cpp 19 Mar 2005 00:16:43 -0000 1.1 > +++ adobe-source/adobe/source/virtual_machine.cpp 9 Apr 2005 12:32:21 -0000 > @@ -445,7 +445,9 @@ > adobe::value_t& operand1((iter - 2)->value_m); > adobe::value_t& operand2((iter - 1)->value_m); > > - operand1.set(operator_class()(operand1.template get<operand_t>(), operand2.template get<operand_t>())); > + operand1.set(operator_class() > + ( static_cast<operand_t>(operand1.template get<operand_t>()) > + , static_cast<operand_t>(operand2.template get<operand_t>()) )); > > contributing_t& contributing1((iter - 2)->contributing_m); > contributing_t& contributing2((iter - 1)->contributing_m); > @@ -523,7 +525,8 @@ > } > else > { > - result = (operand1.value_m.get<adobe::array_t>()[operand2.value_m.get<adobe::array_t::size_type>()]); > + result = (operand1.value_m.get<adobe::array_t>() > + [static_cast<size_t>(operand2.value_m.get<adobe::array_t::size_type>())]); > } > > operand1.value_m = result; > @@ -588,7 +591,9 @@ > > void virtual_machine_t::implementation_t::array_operator() > { > - stack_type::difference_type count (back().value_m.get<stack_type::difference_type>()); > + stack_type::difference_type count > + (static_cast<ptrdiff_t>(back().value_m.get<stack_type::difference_type>())); > + > pop_back(); > > adobe::array_t result; > @@ -618,7 +623,10 @@ > > void virtual_machine_t::implementation_t::dictionary_operator() > { > - stack_type::difference_type count (2 * back().value_m.get<stack_type::difference_type>()); > + stack_type::difference_type count > + (static_cast<ptrdiff_t>(2 * back().value_m.get<stack_type::difference_type>())); > + > + > pop_back(); > > adobe::dictionary_t result; > Index: adobe-source/adobe/source/xstr.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/source/xstr.cpp,v > retrieving revision 1.2 > diff -u -r1.2 xstr.cpp > --- adobe-source/adobe/source/xstr.cpp 7 Apr 2005 23:35:15 -0000 1.2 > +++ adobe-source/adobe/source/xstr.cpp 9 Apr 2005 12:40:30 -0000 > @@ -343,7 +343,7 @@ > > // don't compare the value_m of the node, because it is not essential data > > - return node_attribute_likeness(x, y) == x.attribute_set_m.size(); > + return static_cast<size_t>(node_attribute_likeness(x, y)) == x.attribute_set_m.size(); > } > > /*************************************************************************************************/ > @@ -598,7 +598,7 @@ > for (; first != last; ++first) > { > adobe::name_t name(first->first); > - adobe::name_t att_value(first->second.template get<adobe::name_t>()); > + adobe::name_t att_value(first->second.get<adobe::name_t>()); > > result.push_back(std::make_pair(name, att_value)); > } > Index: adobe-source/adobe/test/eve_smoke/main.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/eve_smoke/main.cpp,v > retrieving revision 1.1 > diff -u -r1.1 main.cpp > --- adobe-source/adobe/test/eve_smoke/main.cpp 30 Mar 2005 22:34:36 -0000 1.1 > +++ adobe-source/adobe/test/eve_smoke/main.cpp 9 Apr 2005 13:05:56 -0000 > @@ -135,4 +135,5 @@ > } > > return success ? 0 : 1; > -} > \ No newline at end of file > +} > + > Index: adobe-source/adobe/test/visual/Jamfile > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/Jamfile,v > retrieving revision 1.6 > diff -u -r1.6 Jamfile > --- adobe-source/adobe/test/visual/Jamfile 8 Apr 2005 21:03:49 -0000 1.6 > +++ adobe-source/adobe/test/visual/Jamfile 9 Apr 2005 14:45:58 -0000 > @@ -9,22 +9,25 @@ > { > PLATFORM_HEADERS = headers/win resources ; > PLATFORM_SOURCE_DIR = sources/win ; > - PLATFORM_SOURCES = sources/win/metrics.cpp sources/win/event_dispatcher.cpp resources/resources.rc ; > + PLATFORM_SOURCES = sources/win/metrics.cpp sources/win/event_dispatcher.cpp ; > # > # These two definitions say that we're targetting Windows XP. That > # means that we get various preprocessor definitions which we need, > # such as the WS_EX_COMPOSITED window style. > # > PLATFORM_DEFINITIONS = <define>WINVER=0x501 <define>_WIN32_WINNT=0x501 ; > + PLATFORM_GCC_LINKFLAGS = "-lgdi32 -luser32 -lcomctl32" ; > } else { > PLATFORM_HEADERS = headers/mac ; > PLATFORM_SOURCE_DIR = sources/mac ; > PLATFORM_SOURCES = ; > PLATFORM_DEFINITIONS = ; > + PLATFORM_GCC_LINKFLAGS = ; > } > > project adobe/visual > : requirements <toolset>msvc:<linkflags>"gdi32.lib user32.lib comctl32.lib /subsystem:windows" > + : requirements <toolset>gcc:<linkflags>$(PLATFORM_GCC_LINKFLAGS) > : requirements <include>headers <link>static > ; > > @@ -37,5 +40,5 @@ > $(PLATFORM_SOURCE_DIR)/display.cpp > $(PLATFORM_SOURCE_DIR)/ui_core_implementation.cpp > /adobe//asl_lib_dev > - /boost/filesystem//boost_filesystem > + /boost/filesystem//boost_filesystem > : <include>$(PLATFORM_HEADERS) $(PLATFORM_DEFINITIONS) <link>static ; > Index: adobe-source/adobe/test/visual/headers/ui_core.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/headers/ui_core.hpp,v > retrieving revision 1.4 > diff -u -r1.4 ui_core.hpp > --- adobe-source/adobe/test/visual/headers/ui_core.hpp 3 Apr 2005 00:31:38 -0000 1.4 > +++ adobe-source/adobe/test/visual/headers/ui_core.hpp 9 Apr 2005 10:41:11 -0000 > @@ -246,9 +246,9 @@ > template <typename Numeric> > std::string format(const Numeric& x) > { > -#if ADOBE_PLATFORM_MAC > +#if ADOBE_PLATFORM_MAC || defined(__MINGW32__) > return format<adobe::value_t>(adobe::value_t(x)); > -#elif defined(BOOST_MSVC) > +#elif defined(BOOST_MSVC) > // Stub for now because the above produces and internal compiler error in MSVC. > std::stringstream stream; > stream << x; > @@ -259,9 +259,9 @@ > template <typename Numeric> > Numeric parse(const std::string& str, adobe::value_t = adobe::value_t()) > { > -#if ADOBE_PLATFORM_MAC > +#if ADOBE_PLATFORM_MAC || defined(__MINGW32__) > return parse<adobe::value_t>(str, adobe::value_t(Numeric())).template get<Numeric>(); > -#elif defined(BOOST_MSVC) > +#elif defined(BOOST_MSVC) > return Numeric(std::atof(str.c_str())); // Stub for now because the above produces and internal compiler error in MSVC. > #endif > } > Index: adobe-source/adobe/test/visual/headers/win/ui_core_implementation.hpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/headers/win/ui_core_implementation.hpp,v > retrieving revision 1.9 > diff -u -r1.9 ui_core_implementation.hpp > --- adobe-source/adobe/test/visual/headers/win/ui_core_implementation.hpp 8 Apr 2005 21:03:50 -0000 1.9 > +++ adobe-source/adobe/test/visual/headers/win/ui_core_implementation.hpp 9 Apr 2005 14:24:21 -0000 > @@ -120,11 +120,11 @@ > > HWND control_m; > WNDPROC default_window_proc_m; > + int uxtheme_type_m; > theme_t theme_m; > implementation::control_focus_proc_t focus_proc_m; > rectangle_t geometry_m; // saving set_bounds param for essentials > point_t position_m; // saving set_bounds param for widget framing > - int uxtheme_type_m; > static HWND invisible_parent_m; // an invisible window used as the initial parent for all controls. > event_dispatcher::reference event_dispatcher_m; // ref. to singleton event dispatcher. > HMENU child_id_m; // this control_m's child id. > @@ -452,9 +452,9 @@ > //HWND scroll_control_m; > bool static_disabled_m; > bool using_label_m; > - bool scrollable_m; > long rows_m; > long cols_m; > + bool scrollable_m; > long edit_baseline_m; > long edit_height_m; > long static_baseline_m; > Index: adobe-source/adobe/test/visual/sources/client_assembler.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/sources/client_assembler.cpp,v > retrieving revision 1.5 > diff -u -r1.5 client_assembler.cpp > --- adobe-source/adobe/test/visual/sources/client_assembler.cpp 31 Mar 2005 01:37:33 -0000 1.5 > +++ adobe-source/adobe/test/visual/sources/client_assembler.cpp 9 Apr 2005 13:37:44 -0000 > @@ -261,12 +261,12 @@ > { } > > adobe::assemblage_t& assemblage_m; > - adobe::window_t* root_m; > adobe::sheet_t& sheet_m; > - eve_client::eve_client_holder& holder_m; > adobe::eve_t& layout_m; > + eve_client::eve_client_holder& holder_m; > eve_client::button_notifier_t notifier_m; > size_enum_t dialog_size_m; > + adobe::window_t* root_m; > }; > > /****************************************************************************************************/ > @@ -508,12 +508,12 @@ > } > > std::string name_m; > - adobe::name_t modifiers_m; > - adobe::name_t action_m; > adobe::name_t bind_m; > adobe::name_t bind_output_m; > + adobe::name_t action_m; > adobe::value_t value_m; > adobe::dictionary_t contributing_m; > + adobe::name_t modifiers_m; > }; > > adobe::button_t button_m; > @@ -749,8 +749,8 @@ > void monitor_value(const adobe::value_t&); > void control_value(std::size_t new_value); > > - std::size_t last_m; // Used to debounce > double value_m; > + std::size_t last_m; // Used to debounce > adobe::slider_t control_m; > format_t format_m; > > @@ -1572,9 +1572,9 @@ > client_proxy_t* parent) : > client_proxy_t(parameters), > characters_m(edit_text_characters), > + num_lines_m(1), > value_ref_m(0), > - edit_active_ref_m(0), > - num_lines_m(1) > + edit_active_ref_m(0) > { > bool monospaced(false); > bool scrollable(false); > @@ -1812,11 +1812,11 @@ > popup_height_m(0), > popup_adjust_m(0), > #endif > + monospaced_m(false), > + go_static_m(false), > value_ref_m(0), > edit_active_ref_m(0), > - static_active_ref_m(0), > - go_static_m(false), > - monospaced_m(false) > + static_active_ref_m(0) > { > std::string format("#.00"); > > @@ -1942,7 +1942,7 @@ > > std::size_t edit_number_proxy_t::popup_index() > { > - for (long value(0); value < units_m.size(); ++value) > + for (size_t value(0); value < units_m.size(); ++value) > if (units_m[value] == unit_value_m) return value; > > return 0; > @@ -2339,7 +2339,7 @@ > > if (show_value_m.type() == typeid(adobe::empty_t)) > { > - if (tab_parent && tab_parent->panel_index_m < tab_parent->items_m.size()) > + if (tab_parent && static_cast<size_t>(tab_parent->panel_index_m) < tab_parent->items_m.size()) > show_value_m = tab_parent->items_m[tab_parent->panel_index_m++].get<adobe::dictionary_t>()[key_value]; > } > > @@ -2849,10 +2849,10 @@ > mac_token_t& token, > client_proxy_t*) : > client_proxy_t(parameters), > + layout_m(NULL), > grow_m(false), > metal_m(false), > - inited_m(false), > - layout_m(NULL) > + inited_m(false) > { > parameters.get<adobe::name_t>(key_target, target_m); > parameters.get<bool>(key_grow, grow_m); > @@ -3196,8 +3196,8 @@ > /****************************************************************************************************/ > > window_server_t::window_server_t(const char* directory_path, adobe::sheet_t& sheet) : > - directory_path_m(directory_path), > - sheet_m(sheet) > + sheet_m(sheet), > + directory_path_m(directory_path) > { } > > /****************************************************************************************************/ > Index: adobe-source/adobe/test/visual/sources/win/metrics.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/sources/win/metrics.cpp,v > retrieving revision 1.4 > diff -u -r1.4 metrics.cpp > --- adobe-source/adobe/test/visual/sources/win/metrics.cpp 8 Apr 2005 21:03:50 -0000 1.4 > +++ adobe-source/adobe/test/visual/sources/win/metrics.cpp 9 Apr 2005 13:43:01 -0000 > @@ -15,6 +15,7 @@ > #include "metrics.hpp" > > #include <sstream> > +#include <stdexcept> > /****************************************************************************************************/ > > namespace adobe > @@ -40,6 +41,8 @@ > return class_name_m; > } > public: > + virtual ~metrics_win32_t() { } > + > // > // from metrics_t > // > @@ -232,8 +235,8 @@ > GetThemeTextMetrics_t GetThemeTextMetricsPtr; > GetThemeFont_t GetThemeFontPtr; > GetThemeSysFont_t GetThemeSysFontPtr; > - DrawThemeParentBackground_t DrawThemeParentBackgroundPtr; > IsThemeActive_t IsThemeActivePtr; > + DrawThemeParentBackground_t DrawThemeParentBackgroundPtr; > // > // We only ever try to load UxTheme.DLL once, this boolean tells us if we were > // successful. > Index: adobe-source/adobe/test/visual/sources/win/ui_core_implementation.cpp > =================================================================== > RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/test/visual/sources/win/ui_core_implementation.cpp,v > retrieving revision 1.13 > diff -u -r1.13 ui_core_implementation.cpp > --- adobe-source/adobe/test/visual/sources/win/ui_core_implementation.cpp 8 Apr 2005 21:03:50 -0000 1.13 > +++ adobe-source/adobe/test/visual/sources/win/ui_core_implementation.cpp 9 Apr 2005 14:34:13 -0000 > @@ -5,6 +5,7 @@ > */ > > /****************************************************************************************************/ > +#define _WIN32_IE 0x0501 > > #include "ui_core_implementation.hpp" > > @@ -430,8 +431,9 @@ > try > { > static const long link_line_width(2); > - HWND parent(::GetAncestor(link.control_m, GA_ROOT)); > - long num_prongs(link.prongs_m.size()); > + // currently unused > + // HWND parent(::GetAncestor(link.control_m, GA_ROOT)); > + size_t num_prongs(link.prongs_m.size()); > RECT bounds = { 0 }; > point_set_t points; > std::string link_icon_name("link_icon.png"); > @@ -477,9 +479,10 @@ > > bounds.right += 2; // reset inset for the link icon > > - short center = bounds.top + > - link.prongs_m[0] - link_line_width + > - (link.prongs_m[num_prongs - 1] - link.prongs_m[0]) / 2; > + // currently unused > + // short center = bounds.top + > + // link.prongs_m[0] - link_line_width + > + // (link.prongs_m[num_prongs - 1] - link.prongs_m[0]) / 2; > > // draw link icon here at { bounds.right - 5, center - 8, 9, 16 } > } > @@ -965,7 +968,7 @@ > template <typename T> > T number_parse(const std::string& format, const std::string& str) > { > - return std::atof(str.c_str()); > + return static_cast<T>( std::atof(str.c_str()) ); > } > > /****************************************************************************************************/ > @@ -1012,9 +1015,9 @@ > { > if (false) { } > else if (x.type() == typeid(char)) return number_format<char>(format_m, x.get<char>()); > - else if (x.type() == typeid(short)) return number_format<short>(format_m, x.get<short>()); > - else if (x.type() == typeid(int)) return number_format<int>(format_m, x.get<int>()); > - else if (x.type() == typeid(long)) return number_format<long>(format_m, x.get<long>()); > + else if (x.type() == typeid(short)) return number_format<short>(format_m, static_cast<short>(x.get<short>())); > + else if (x.type() == typeid(int)) return number_format<int>(format_m, static_cast<int>(x.get<int>())); > + else if (x.type() == typeid(long)) return number_format<long>(format_m, static_cast<long>(x.get<long>())); > else if (x.type() == typeid(long long)) return number_format<long long>(format_m, x.get<long long>()); > else if (x.type() == typeid(float)) return number_format<float>(format_m, x.get<float>()); > else if (x.type() == typeid(double)) return number_format<double>(format_m, x.get<double>()); > @@ -1437,9 +1440,9 @@ > int top; > > if (position == window_reposition_center_s) > - top = std::max<int>(10, (sys_met_y - height)/2); > + top = static_cast<int>(std::max<int>(10, (sys_met_y - height)/2)); > else //if (position == window_reposition_alert_s) > - top = std::max<int>(10, (sys_met_y * .6 - height)/2); > + top = std::max<int>(10, static_cast<int>((sys_met_y * .6 - height)/2)); > > ::MoveWindow(window_m, left, top, width, height, TRUE); > } > @@ -1573,7 +1576,7 @@ > /****************************************************************************************************/ > > control_t::control_t() : > - control_m(0), uxtheme_type_m(0), theme_m(theme_default_s), default_window_proc_m(0), > + control_m(0), default_window_proc_m(0), uxtheme_type_m(0), theme_m(theme_default_s), > child_id_m(0) > #ifndef NDEBUG > , placed_m(false) > @@ -1622,7 +1625,7 @@ > /****************************************************************************************************/ > > control_t::control_t(const control_t& rhs) : > - control_m(0), uxtheme_type_m(0), theme_m(rhs.theme_m), default_window_proc_m(0), > + control_m(0), default_window_proc_m(0), uxtheme_type_m(0), theme_m(rhs.theme_m), > child_id_m(0) > #ifndef NDEBUG > , placed_m(false) > @@ -1890,7 +1893,7 @@ > > void control_t::user_hit() > { > - ::MessageBeep(-1); > + ::MessageBeep( static_cast<UINT>(-1) ); > } > > /****************************************************************************************************/ > @@ -2042,7 +2045,8 @@ > > _super::set_theme(theme); > > - theme_t masked(theme & theme_mask_s); > + // currently unused > + // theme_t masked(theme & theme_mask_s); > } > > /****************************************************************************************************/ > @@ -2258,7 +2262,7 @@ > { > assert(control_m); > > - BS_DEFPUSHBUTTON; > +// BS_DEFPUSHBUTTON; > // set_widget_data(control_m, kControlEntireControl, > // kControlPushButtonDefaultTag, Boolean(is_default)); > } > @@ -3045,7 +3049,7 @@ > using_label_m(rhs.using_label_m), rows_m(rhs.rows_m), > cols_m(rhs.cols_m), scrollable_m(rhs.scrollable_m), > edit_baseline_m(rhs.edit_baseline_m), edit_height_m(rhs.edit_height_m), > - static_height_m(rhs.static_height_m), static_baseline_m(rhs.static_baseline_m) > + static_baseline_m(rhs.static_baseline_m), static_height_m(rhs.static_height_m) > { > RECT bounds = { 0 }; > > @@ -3376,18 +3380,18 @@ > /****************************************************************************************************/ > > popup_t::implementation_t::implementation_t() : > - static_disabled_m(false), using_label_m(false), static_baseline_m(0), static_height_m(0), > - popup_baseline_m(0), popup_height_m(0) > + static_disabled_m(false), static_baseline_m(0), static_height_m(0), > + popup_baseline_m(0), popup_height_m(0), using_label_m(false) > { > } > > /****************************************************************************************************/ > > popup_t::implementation_t::implementation_t(const implementation_t& rhs) : > - _super(rhs), static_disabled_m(rhs.static_disabled_m), > - using_label_m(rhs.using_label_m), name_m(rhs.name_m), > + _super(rhs), name_m(rhs.name_m), static_disabled_m(rhs.static_disabled_m), > static_baseline_m(rhs.static_baseline_m), static_height_m(rhs.static_height_m), > - popup_baseline_m(rhs.popup_baseline_m), popup_height_m(rhs.popup_height_m) > + popup_baseline_m(rhs.popup_baseline_m), popup_height_m(rhs.popup_height_m), > + using_label_m(rhs.using_label_m) > { > RECT bounds = { 0 }; > > @@ -3493,7 +3497,8 @@ > if (GetComboBoxInfo(control_m, &cbi)) > { > RECT text = { 0, 0, 0, 0 }; > - RECT size = { 0, 0, 0, 0 }; > + // currently unused > + // RECT size = { 0, 0, 0, 0 }; > WINDOWINFO wi = { 0 }; > wi.cbSize = sizeof(wi); > if (!GetWindowInfo(control_m, &wi)) ADOBE_THROW_LAST_ERROR; > @@ -4077,6 +4082,7 @@ > case slider_points_left_s: win32_style |= TBS_LEFT; break; > case slider_points_down_s: win32_style |= TBS_BOTTOM; break; > case slider_points_right_s: win32_style |= TBS_RIGHT; break; > + default: /* eliminates gcc warning */ break; > } > } > else > @@ -4390,10 +4396,10 @@ > assert(!control_m); > assert(window); > > +#if 0 > RECT one_bounds = { 0, 0, 1, 1 }; > RECT global_bounds; > > -#if 0 > static ControlUserPaneDrawUPP draw_handler(::NewControlUserPaneDrawUPP(draw_hitless)); > > host_window_m = window; > @@ -4441,9 +4447,9 @@ > > void hitless_t::implementation_t::overlay_bounds_update() > { > +#if 0 > RECT overlay_bounds = { 0 }; > RECT hosting_bounds = { 0 }; > -#if 0 > WindowClass host_window_class(0); > > ADOBE_REQUIRE_STATUS(::GetWindowClass(host_window_m, &host_window_class)); > > > |
|
From: Ralph T. <ra...@gm...> - 2005-04-11 06:46:51
|
Hi everybody, What are the steps we need to take to turn the visual test into a library? The things I want to be able to do with it are: * Load Adam and Eve files and have the relations between them linked up. * Register my own widget types, in addition to those provided by ui-core. * Register my own function callbacks, like @ok. Maybe (although certainly for custom widgets): * Bind callback functions to cells (to be informed about cell changes). What other requirements are there for a visual library? Thanks! Ralph |
|
From: Tobias S. <tsc...@ne...> - 2005-04-10 16:06:39
|
I accidently sent my reply to Ralph instead to the list - it was actually intended to go here (especially because of that runtime issue mentioned in the last paragraph): -------- Original Message -------- Ralph Thomas wrote: >On Apr 8, 2005 2:04 PM, Tobias Schwinger <tsc...@ne...> wrote: > > >>All builds have been done via Boost.Jam and I had to tweak >>"boost/thread/detail/config.hpp" for static linkage because the >>BOOST_THREAD_DECL macro expands to an invalid DLL-import attribute (I >>guess this has to do with Boost.Build V2 since I never had this problem >>building Boost with V1. Does "proper mechanism" in the "new build >>structure" thread refer to using Boost.Build V1 for the Boost libraries >>? If so, this is probably already fixed in the Sandbox). >> >> > >We're still using Boost.Build V2, and I can't figure out how to make >Boost.Thread build without changing it's Jamfile. The change which I >have used is at the head of boost/libs/thread/build/Jamfile.v2 -- I >add "<link>static:<define>BOOST_THREAD_USE_LIB=1" under the similar >line for correctly making a DLL build. I don't know why Boost.Thread >doesn't respect the static linking flag in >sandbox/adobe-source/adobe/build -- all of the other boost libraries >seem to. > > ... or "BOOST_THREAD_USE_DLL" is defined accidently and "BOOST_THREAD_USE_LIB" is not considered by the config header beacause of this. >On the plus side, Foster has done a good job at making sure that >things build properly when using the *.vcproj files (with the IDE) -- >unfortunately I don't think that the VC++ Toolbox comes with a tool to >build from those. > > > >>All examples that can be built with MinGW work fine. The "visual" >>example cannot be built, due to the lack of XP-Theme support in the >>current MinGW distribution. However, I used 'uxtheme.h' (and "friends") >>from the Platform-SDK in order to ensure everything compiles fine >>(linking fails then). >> >> > >How does linking fail? I just removed the reference to uxtheme.lib >from the Jamfile because uxtheme.dll is opened dynamically now (so >that generated binaries run fine on Windows pre-XP). I'd really >appreciate it if you could try again with the current sandbox. > > It did not compile OOTB (see attached patch, I also removed most warnings while at it). Uxtheme dependencies are gone now. Further I had to adjust the Jamfile so GCC sees something like "-lgdi32 -luser32..." when linking (or it will find nothing at all). There was another problem with the Jamfile regarding the generation of the resource header (just disabled it for anything other than MSVC - probably the Boost.Build system does not know about the MinGW resource compiler). After the CVS update the GCC-compiled examples fail with a "syntax error exception". Please let me know in case there's anything I can do to help (and what to look for) tracking this down. Regards, Tobias |
|
From: Ralph T. <ra...@gm...> - 2005-04-08 22:41:31
|
[ I think my message got tagged as SPAM; I got a bounce message from sourceforge -- hopefully this time it'll go through -- apologies for any duplicates]. On Apr 8, 2005 2:04 PM, Tobias Schwinger <tsc...@ne...> wrote: > All builds have been done via Boost.Jam and I had to tweak > "boost/thread/detail/config.hpp" for static linkage because the > BOOST_THREAD_DECL macro expands to an invalid DLL-import attribute (I > guess this has to do with Boost.Build V2 since I never had this problem > building Boost with V1. Does "proper mechanism" in the "new build > structure" thread refer to using Boost.Build V1 for the Boost libraries > ? If so, this is probably already fixed in the Sandbox). We're still using Boost.Build V2, and I can't figure out how to make Boost.Thread build without changing it's Jamfile. The change which I have used is at the head of boost/libs/thread/build/Jamfile.v2 -- I add "<link>static:<define>BOOST_THREAD_USE_LIB=1" under the similar line for correctly making a DLL build. I don't know why Boost.Thread doesn't respect the static linking flag in sandbox/adobe-source/adobe/build -- all of the other boost libraries seem to. On the plus side, Foster has done a good job at making sure that things build properly when using the *.vcproj files (with the IDE) -- unfortunately I don't think that the VC++ Toolbox comes with a tool to build from those. > All examples that can be built with MinGW work fine. The "visual" > example cannot be built, due to the lack of XP-Theme support in the > current MinGW distribution. However, I used 'uxtheme.h' (and "friends") > from the Platform-SDK in order to ensure everything compiles fine > (linking fails then). How does linking fail? I just removed the reference to uxtheme.lib from the Jamfile because uxtheme.dll is opened dynamically now (so that generated binaries run fine on Windows pre-XP). I'd really appreciate it if you could try again with the current sandbox. Thanks! Ralph |
|
From: Tobias S. <tsc...@ne...> - 2005-04-08 21:04:50
|
Hello, I finally found the time to practically evaluate this wonderful and very promising set of components. It took me some time to figure out the "right" compiler, so I made it build with VC8 and GCC 3.4 (MinGW windows port) along the way. I used VC7.1 (Toolkit 2003 - the free version of the optimizing compiler) for the final build with all examples working properly (static linkage, static runtime build settings). Since the patch files may probably contain something of interest to you, I decided to post them here. Here are my annotations: All builds have been done via Boost.Jam and I had to tweak "boost/thread/detail/config.hpp" for static linkage because the BOOST_THREAD_DECL macro expands to an invalid DLL-import attribute (I guess this has to do with Boost.Build V2 since I never had this problem building Boost with V1. Does "proper mechanism" in the "new build structure" thread refer to using Boost.Build V1 for the Boost libraries ? If so, this is probably already fixed in the Sandbox). All examples that can be built with MinGW work fine. The "visual" example cannot be built, due to the lack of XP-Theme support in the current MinGW distribution. However, I used 'uxtheme.h' (and "friends") from the Platform-SDK in order to ensure everything compiles fine (linking fails then). I had to overload operator() for a "key_type,entry_type" signature in 'static_table.hpp' and 'source/virtual_machine.cpp' to work with the new standard library of VC8-beta, this fix is probably not exactly perfect and feels really suspicious... Built with VC8-beta the "eve_smoke" example works fine. The "adam_tutorial" basically works, but crashes when changing values (this has already been reported in the forum - might have something to do with the paranoid range checks in the new STL). The "visual" example asserts in the "eve_t::implementation_t::solve" member function in 'source/eve.cpp' (would solve forever;-). That's it for now. I'm looking forward to learn how to use these awesome tools, now that I have a working environment ! Thank you, Tobias |
|
From: Sean P. <sp...@ad...> - 2005-04-05 22:02:31
|
We've gone back and forth on this - for the ui-core, I'm fine with putting it in the file directly (I think the UI code is still at the stage of just being example code - still needs a lot of work before I'd promote it to the library). We can always split the docs out later (the hard part is writing them!). Sean On Apr 5, 2005, at 1:08 AM, Ralph Thomas wrote: > Hi list, > > I've started work on documenting the ui-core API. The rest of the > ASL documentation is done using external doxygen files. I'd much > rather use inline doxygen, because I think this is easier to maintain > (as I'm more likely to remember to update the documentation when I > change an API if the documentation is at the same place), and because > I don't like to switch between my text editor and a documentation > viewer. > > What are your opinions? > > Thanks, > Ralph > > PS: The dox files in documentation/concepts have the wrong copyright > notice on. > > > ------------------------------------------------------- > 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: Sean P. <sp...@ad...> - 2005-04-05 20:02:26
|
On Apr 5, 2005, at 12:10 PM, David Catmull wrote: > On Apr 5, 2005, at 11:42 AM, Sean Parent wrote: >> I'm not sure what you mean by "examine for compatibility" but you can >> retrieve the type of an adobe::value_t using the value_t::type() >> member function. > > The clipboard must be examined to determine if its contents are > compatible with the subject and can be pasted. This array is, in > effect, the wrapper around the platform clipboard interface, correct? The connection with the platform clipboard interface (which probably has some set of interchange types and promises) would be handled by feeding that data into (and out from) the internal array. Not everything in the internal array could be fed to the platform clipboard "compatibility" for paste would be handled by our previously mentioned "is_convertible" function. The question is, is the contents of the clipboard convertible to the value type of the destination. This could be handled in the same way that value_t currently handles promotion of type - but would allow for lossy conversions (handling paths through the conversion process would be interesting but I don't think necessary as all the data types are known). 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-04-05 19:10:54
|
On Apr 5, 2005, at 11:42 AM, Sean Parent wrote: > I'm not sure what you mean by "examine for compatibility" but you can > retrieve the type of an adobe::value_t using the value_t::type() > member function. The clipboard must be examined to determine if its contents are compatible with the subject and can be pasted. This array is, in effect, the wrapper around the platform clipboard interface, correct? -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Sean P. <sp...@ad...> - 2005-04-05 18:42:19
|
On Apr 5, 2005, at 8:56 AM, David Catmull wrote:
> On Apr 4, 2005, at 2:02 PM, Sean Parent wrote:
>> This implies our clipboard (as the default source) - could be
>> implemented as as std::vector<adobe::value_t> (or an adobe::array_t)
>> with the source being the range [begin(clipboard), end(clipboard) ) .
>
> How would you examine such a clipboard for compatibility? What are the
> elements of the array?
The elements of the array or vector are whatever was cut (an
adobe::value_t can hold any regular type) - I'm not sure what you mean
by "examine for compatibility" but you can retrieve the type of an
adobe::value_t using the value_t::type() member function.
>
>> is_copyable(source, destination) { return !empty(source) &&
>> mutable(destination) && contiguous(destination) &&
>> convertible(source, value_type(destination)); }
>
> What does "contiguous" refer to in this context?
A single range - inserting into multiple ranges would be disallowed
(mostly because I'm not sure what it would mean).
>
> --
> 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: Sean P. <sp...@ad...> - 2005-04-05 18:39:24
|
On Apr 5, 2005, at 8:56 AM, David Catmull wrote: > On Apr 4, 2005, at 12:51 PM, Sean Parent wrote: >> I'm still struggling with how to fully represent a subject but I do >> know that it needs to be able to represent collections within a >> container as well as ranges (perhaps a collection is represented as a >> list of ranges to merge the two concepts). > > I thought of a few different types of selections and insertion points > as I was examining that idea. Again, I define "insertion point" as a > location for inserting data (pasted or dropped), and the "current" > insertion point is where pasted data would go. > > Ranges > Mainly seen in text. A selection is a range, from a start index to > and end index. The distinction between selection and insertion point > is blurry or nonexistant. New content placed at the current insertion > point replaces the selection. Ranges come up in many places - a selection in a scrolling list. This is why I proposed the notion of a collection - which would be a list of ranges, an insertion point is simply a collection comprised of a single empty range. A contiguous collection is a single range (empty or non-empty) which can also serve as an "insertion point" for operations which do a replace. > > List > A list or collection of items. A selection is a subset of the > items. If the order of the items is determined by the user, then an > insertion point indicates a position between two elements. If the > items are sorted, then the insertion point indicates "somewhere" in > the list, to be determined when the new content is received. This > could include hierarchical lists too, where an insertion point would > include a reference to a parent item. You can have a range within a hierarchy also (see the adobe::forest<> container). > > Arrangement > As in drawing applications like Illustrator: a collection of > objects in n-space (where n is usually 2). A selection is a set of > objects, and an insertion point is a location within the space. The > current insertion point is the center of the space or of the view, or > in some apps it can be center of the selection. I don't see a need for this yet - in Illustrator a collection of n objects is not denoted geometrically, rather by a collection within the art tree (using collection here as a defined it above). An "insertion point" is a location in the art tree and an x,y coordinate which is also part of the subject and applied to the new items. I'm not sure that this implies a transformation on inserted objects, or simply that new nodes in the tree pick up a default x,y location (artwork outside the tree only has relative positions). > > I think Photoshop fits in the Arrangement category, though its > floating selections are more complex, since they re-merge with the > current layer when deselected. I'm tempted to make a separate category > for that. Photoshop is actually simpler (and similar) - the "selection" in Photoshop is not a selection as denoted here - it is itself a channel which is part of the subject. > > -- > 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: Foster T. B. <fbr...@ad...> - 2005-04-05 17:57:05
|
On Apr 5, 2005, at 10:34a, Sean Parent wrote:
> You could - but use name_t instead of std::string (these are immutable
> strings that will exist for the duration of the application). What's
> the required_m member for?
required_m specifies whether or not the xstr was parsed as an xstr that
needed to be in the dictionary, or if a default value was supplied.
I'll use name_t.
> There is a tradeoff to be aware of - by storing it flat it is easy to
> cache the index in a file and startup quickly with a quick "slurp" of
> the glossary and index. You can probably come up with a cache
> mechanism for this form but it will be a bit more difficult (startup
> time is important enough that at some point we'll want to avoid
> parsing a large glossary file at startup).
> Sean
This is an interesting problem-- I'll have to think about it a bit more.
Blessings,
Foster
> On Apr 5, 2005, at 9:55 AM, Foster T. Brereton wrote:
>
>> On Apr 4, 2005, at 09:39p, Sean Parent wrote:
>>
>>> I would store the strings in a string pool (like name_t) - except
>>> index them with a multimap by id.
>>
>> Another issue--
>>
>> In order for me to store the xstr by id, I first have to parse it in
>> order to figure out what the id is, as it will be an attribute of the
>> xstr. But then I go and store it in the pool as a raw string? If I
>> wanted to get an xstr out of the pool, I'd first have to parse the
>> search xstr, then parse each xstr in the pool to come up with the
>> list of possible matches. Would it make more sense to store them as a
>> processed xstr:
>>
>> struct node_t
>> {
>> typedef std::pair<std::string, std::string> attribute_t;
>> typedef std::vector<attribute_t> attribute_set_t;
>>
>> // code removed for brevity's sake
>>
>> attribute_set_t attribute_set_m;
>> std::string value_m;
>> bool required_m;
>> };
>>
>> And the pool would then be:
>>
>> typedef std::multimap<const char*, node_t, str_less> store_t;
>>
>> Thoughts?
>>
>> 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
>>
>
>
>
> -------------------------------------------------------
> 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
>
>
--
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...> - 2005-04-05 17:34:34
|
You could - but use name_t instead of std::string (these are immutable
strings that will exist for the duration of the application). What's
the required_m member for?
There is a tradeoff to be aware of - by storing it flat it is easy to
cache the index in a file and startup quickly with a quick "slurp" of
the glossary and index. You can probably come up with a cache mechanism
for this form but it will be a bit more difficult (startup time is
important enough that at some point we'll want to avoid parsing a large
glossary file at startup).
Sean
On Apr 5, 2005, at 9:55 AM, Foster T. Brereton wrote:
> On Apr 4, 2005, at 09:39p, Sean Parent wrote:
>
>> I would store the strings in a string pool (like name_t) - except
>> index them with a multimap by id.
>
> Another issue--
>
> In order for me to store the xstr by id, I first have to parse it in
> order to figure out what the id is, as it will be an attribute of the
> xstr. But then I go and store it in the pool as a raw string? If I
> wanted to get an xstr out of the pool, I'd first have to parse the
> search xstr, then parse each xstr in the pool to come up with the list
> of possible matches. Would it make more sense to store them as a
> processed xstr:
>
> struct node_t
> {
> typedef std::pair<std::string, std::string> attribute_t;
> typedef std::vector<attribute_t> attribute_set_t;
>
> // code removed for brevity's sake
>
> attribute_set_t attribute_set_m;
> std::string value_m;
> bool required_m;
> };
>
> And the pool would then be:
>
> typedef std::multimap<const char*, node_t, str_less> store_t;
>
> Thoughts?
>
> 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-04-05 16:55:23
|
On Apr 4, 2005, at 09:39p, Sean Parent wrote:
> I would store the strings in a string pool (like name_t) - except
> index them with a multimap by id.
Another issue--
In order for me to store the xstr by id, I first have to parse it in
order to figure out what the id is, as it will be an attribute of the
xstr. But then I go and store it in the pool as a raw string? If I
wanted to get an xstr out of the pool, I'd first have to parse the
search xstr, then parse each xstr in the pool to come up with the list
of possible matches. Would it make more sense to store them as a
processed xstr:
struct node_t
{
typedef std::pair<std::string, std::string> attribute_t;
typedef std::vector<attribute_t> attribute_set_t;
// code removed for brevity's sake
attribute_set_t attribute_set_m;
std::string value_m;
bool required_m;
};
And the pool would then be:
typedef std::multimap<const char*, node_t, str_less> store_t;
Thoughts?
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-04-05 16:24:25
|
On Apr 4, 2005, at 09:39p, Sean Parent wrote:
> adobe::xstr_t mystr("<xstr id='ok'/>"); // must be in the dictionary
What happens here if the id is not in the dictionary? Throw? If so, how
can this be done safely, considering we're constructing the xstr_t?
> Some concerns about using the Spirit parser framework - is it thread
> safe, and can we get good error reporting (like the expression parser
> does now)? We'll need both - I don't know the answers to these, it has
> been some time since I've played with Spirit.
Spirit does handle multithreading, and it also has some error reporting
mechanism that we can leverage. I'll investigate both.
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-04-05 15:57:07
|
On Apr 4, 2005, at 12:51 PM, Sean Parent wrote:
> I'm still struggling with how to fully represent a subject but I do
> know that it needs to be able to represent collections within a
> container as well as ranges (perhaps a collection is represented as a
> list of ranges to merge the two concepts).
I thought of a few different types of selections and insertion points
as I was examining that idea. Again, I define "insertion point" as a
location for inserting data (pasted or dropped), and the "current"
insertion point is where pasted data would go.
Ranges
Mainly seen in text. A selection is a range, from a start index to
and end index. The distinction between selection and insertion point is
blurry or nonexistant. New content placed at the current insertion
point replaces the selection.
List
A list or collection of items. A selection is a subset of the
items. If the order of the items is determined by the user, then an
insertion point indicates a position between two elements. If the items
are sorted, then the insertion point indicates "somewhere" in the list,
to be determined when the new content is received. This could include
hierarchical lists too, where an insertion point would include a
reference to a parent item.
Arrangement
As in drawing applications like Illustrator: a collection of
objects in n-space (where n is usually 2). A selection is a set of
objects, and an insertion point is a location within the space. The
current insertion point is the center of the space or of the view, or
in some apps it can be center of the selection.
I think Photoshop fits in the Arrangement category, though its floating
selections are more complex, since they re-merge with the current layer
when deselected. I'm tempted to make a separate category for that.
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: David C. <unc...@un...> - 2005-04-05 15:57:05
|
On Apr 4, 2005, at 2:02 PM, Sean Parent wrote:
> This implies our clipboard (as the default source) - could be
> implemented as as std::vector<adobe::value_t> (or an adobe::array_t)
> with the source being the range [begin(clipboard), end(clipboard) ) .
How would you examine such a clipboard for compatibility? What are the
elements of the array?
> is_copyable(source, destination) { return !empty(source) &&
> mutable(destination) && contiguous(destination) && convertible(source,
> value_type(destination)); }
What does "contiguous" refer to in this context?
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: Ralph T. <ra...@gm...> - 2005-04-05 08:08:30
|
Hi list, I've started work on documenting the ui-core API. The rest of the ASL documentation is done using external doxygen files. I'd much rather use inline doxygen, because I think this is easier to maintain (as I'm more likely to remember to update the documentation when I change an API if the documentation is at the same place), and because I don't like to switch between my text editor and a documentation viewer. What are your opinions? Thanks, Ralph PS: The dox files in documentation/concepts have the wrong copyright notice on. |
|
From: Sean P. <sp...@ad...> - 2005-04-05 06:11:50
|
We have a few pieces of info here:
First we have a primary key (let's use id as the attribute rather than
name - and lower case conventions):
<xstr id='ok'>OK</xstr>
<xstr id='quit'>Quit</xstr>
For a given string we might have alternates with different attributes:
<xstr id='ok' lang='de'>O.K.</xstr>
<xstr id='quit' platform='windows'>Exit</xstr>
We will allow the following for normal attributes - we should have a
list of standard attributes and values:
id, lang, platform, context are a minimum starting point (context
should be provided by Eve - it isn't but we'll fix that).
I would store the strings in a string pool (like name_t) - except index
them with a multimap by id.
For now, I think a linear find function will suffice for items within
the multimap (later we can swap it out for a multi hash map, and
provide some cashed subindex info). Unspecified attributes match any
request, specified attributes must match exactly. Score the matches,
and issue a warning if there are more than one match with the highest
score (this will suffice for now - we may wish to consider a priority
for attributes...).
I should be able to construct one in my code as:
adobe::xstr_t mystr("<xstr id='ok'>OK</xstr>"); // will be added to
dictionary if not present
or
adobe::xstr_t mystr("<xstr id='ok'/>"); // must be in the dictionary
I haven't decided yet if I want context as a parameter or always picked
up from a stack (threading issue here).
We will need a set of functions to strip markup of strings and to
evaluate them (right now I think we can do this on demand - later we'll
probably want to cache). UTF-8 will be common enough that a .get()
method is probably in order.
std::string utf8str (mystr.get());
Some concerns about using the Spirit parser framework - is it thread
safe, and can we get good error reporting (like the expression parser
does now)? We'll need both - I don't know the answers to these, it has
been some time since I've played with Spirit.
Once we have the basic support in - the next step will be to handle
replacement points - replacements (the result of a replacement is never
an xstr - xstrs are not mutable).
std::string utf8str (adobe::replace("<xstr id='size',
context='image_size'>Document Size: <mark index='0'/><mark
index='1'/></xstr>", boost::lexical_cast(35.5), "MB");
Not sure if "<mark/>" is the right name (or if we should be using XML
namespaces all around - I'll ping the localization folks).
Sean
On Apr 4, 2005, at 4:24 PM, Foster T. Brereton wrote:
> All,
>
> How would you recommend we go about searching the xstrings we find?
> Right now I have xstr_t as the collection of strings parsed from the
> file:
>
> <xstr name="OK">OK</xstr>
> <xstr name="Cancel">Cancel</xstr>
> ...
> <xstr name="foo">my foo</xstr>
>
> I was thinking there could be a search operation that would take in a
> named argument and return a new xstr_t that contains all the nodes in
> the superset for which the named argument exists with the specified
> value:
>
> xstr_t xstr_t::subset(const std::string& att_name, const std::string&
> att_value);
>
> We could then write some "whittle down" search until we come up with
> an xstr_t object with one node, and return the content of that node:
>
> std::string xstr_t::search(const std::vector<std::pair<std::string,
> std::string> >& attributes);
>
> It seems heavyweight and expensive, but the advantage is clients can
> "save off" searches, so for instance one could grab all the subsets
> for which "os = mac", and use it repeatedly in looking for, say,
> metric information on widgets. Thoughts?
>
> 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
>
>
>
> -------------------------------------------------------
> 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: Ralph T. <ra...@gm...> - 2005-04-05 05:56:25
|
Hi all! I just committed the Windows support for modifier keys. The mapping is like this: @ctl is the control key (modifiers_any_control_s) @opt is the alt key (modifiers_any_option_s) @cmd is the "popup menu" key (modifiers_any_command_s) It might be a nice idea to put some windows-specific aliases into client_assembler, such that: @alt == @opt @cmd == @popup Are the modifier values documented anywhere? I could only see them in the widget reference. Thanks! Ralph |
|
From: Ralph T. <ra...@gm...> - 2005-04-05 03:01:24
|
That looks great! The only thing I can think about is having a convenient helper function which allowed me to specify a default value, in case the xstr I'm looking for is not defined. So I might have: <xstr name="beans" lang="en-us">garbonzo</xstr> <xstr name="beans" lang="de">kichererbsen</xstr> Then I might want to call bean_name = xstr_t::search(<"lang", "en">, "chickpeas"); And get an "chickpeas" back. It might be extra nice if xstr_t::search was a template function, and could use a stringstream to do type conversions (to the requested template parameter), like: template<typename outtype> outtype xstr_t::search(std::vector<..>& attributes, outtype default); But essentially it looks fine as it is, and is probably much less work than XQuery (both computationally and lines of code). Thanks, Ralph On Apr 4, 2005 4:24 PM, Foster T. Brereton <fbr...@ad...> wrote: > All, > > How would you recommend we go about searching the xstrings we find? > Right now I have xstr_t as the collection of strings parsed from the > file: > > <xstr name="OK">OK</xstr> > <xstr name="Cancel">Cancel</xstr> > ... > <xstr name="foo">my foo</xstr> > > I was thinking there could be a search operation that would take in a > named argument and return a new xstr_t that contains all the nodes in > the superset for which the named argument exists with the specified > value: > > xstr_t xstr_t::subset(const std::string& att_name, const std::string& > att_value); > > We could then write some "whittle down" search until we come up with an > xstr_t object with one node, and return the content of that node: > > std::string xstr_t::search(const std::vector<std::pair<std::string, > std::string> >& attributes); > > It seems heavyweight and expensive, but the advantage is clients can > "save off" searches, so for instance one could grab all the subsets for > which "os = mac", and use it repeatedly in looking for, say, metric > information on widgets. Thoughts? > > 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-04-04 23:24:29
|
All, How would you recommend we go about searching the xstrings we find? Right now I have xstr_t as the collection of strings parsed from the file: <xstr name="OK">OK</xstr> <xstr name="Cancel">Cancel</xstr> ... <xstr name="foo">my foo</xstr> I was thinking there could be a search operation that would take in a named argument and return a new xstr_t that contains all the nodes in the superset for which the named argument exists with the specified value: xstr_t xstr_t::subset(const std::string& att_name, const std::string& att_value); We could then write some "whittle down" search until we come up with an xstr_t object with one node, and return the content of that node: std::string xstr_t::search(const std::vector<std::pair<std::string, std::string> >& attributes); It seems heavyweight and expensive, but the advantage is clients can "save off" searches, so for instance one could grab all the subsets for which "os = mac", and use it repeatedly in looking for, say, metric information on widgets. Thoughts? 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...> - 2005-04-04 21:03:32
|
I had noted that I'm assuming all subjects already meet the requirements for a regular type <http://opensource.adobe.com/group__concept__regular__type.html>. There may be cases where this is too strong (although I really doubt it) - if we had a requirement that "Cut" implies something is available on the shared clipboard (Cut normally doesn't, it is fine to have internal only representations), then there would be some other requirement "convertible_to_export_format(subject)" or some such item. The behavior you describe in CodeWarrior I would consider a bug - at least I can't see a valid reason why a project group isn't a regular type. After I sent my previous note - I realized that Paste has an additional parameter which must be satisfied - namely that we have a valid source - !empty(source) And we probably also need to require that the source type can be converted to the destination type - convertible(source, value_type(subject)) There is a nice symmetry hidden here, paste and copy are the same function with the source/subject reversed (perhaps source is then a bad name... but I can't think of a better at the moment although "predicate noun" would be the obvious choice it would be a horribly confusing one): command(name: "Copy", function: @copy, precondition: !empty(subject) && mutable(source) && contiguous(source) && convertible(subject, value_type(source)); command(name: "Paste", function: @paste, precondition: !empty(source) && mutable(subject) && contiguous(subject) && convertible(source, value_type(subject)); This implies our clipboard (as the default source) - could be implemented as as std::vector<adobe::value_t> (or an adobe::array_t) with the source being the range [begin(clipboard), end(clipboard) ) . We could extract this predicate into a function: is_copyable(source, destination) { return !empty(source) && mutable(destination) && contiguous(destination) && convertible(source, value_type(destination)); } And our descriptions would become (I'll use prenoun instead of source). command(name: "Copy", function: copy(subject, prenoun), precondition: is_copyable(subject, prenoun)); command(name: "Paste", function: copy(prenoun, subject), precondition: is_copyable(prenoun, subject)); Hmmm... There has to be some literature related to this published someplace. Anyone have ideas on where to look? Sean On Apr 4, 2005, at 1:02 PM, David Catmull wrote: > On Apr 4, 2005, at 12:51 PM, Sean Parent wrote: >> command(name: "Cut", function: @cut, precondition: !empty(subject) && >> mutable(subject)); > > The selection must also be copiable. For example, a CodeWarrior > project group can be selected, dragged, and deleted, but not copied. > It's debatable whether this should be so in this specific case, but > there may be other cases where something is selectable but contains > inherently contextual data that cannot be exported. > > Overall, I think it's pretty exciting that we're thinking along the > same lines here. > > -- > 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 |
2 messages has been excluded from this view by a project administrator.
