Menu
▾
▴
adobe-source-devel
|
From: Robert D. <rcd...@gm...> - 2009-05-30 00:56:04
|
Hello, So I've got the Begin app compiling and linking under CMake, however it cannot find resources during the loading process. I pointed the working directory in Visual Studio to the begin/resources directory, but this does not seem to help. I tried referencing the bjam scripts as well, but since I am not familiar with bjam I had trouble finding anything helpful. Can anyone give me some pointers? It is trying to find *glossary.xstr*. |
|
From: Robert D. <rcd...@gm...> - 2009-05-30 19:34:56
|
So I found out that adobe::find_resource() is being used to try to find glossary.xstr. However, it only uses the root_path() for searching, which isn't very flexible at all. How about making this function check a few more places, in particular the working directory. Also, it would be a nice feature to be able to specify a list of resource directories at the command line for the begin app and have those be used for searching for resources, amongst other obvious paths. Doing this will prevent me from having to copy files around via CMake to ensure that resources can be found. I can make these changes myself, if you guys think it would be a good idea. I'm leaning more towards the command-line parameter approach for specifying resource directories. Another comment: The root_path() is basically a singleton, and not thread safe at all. It would be ideal to make resource "hints" a concept, possibly create a new class called ResourceRepository, which can be given directory hints (where to find resources) and can be used to obtain resources. On Fri, May 29, 2009 at 7:56 PM, Robert Dailey <rcd...@gm...> wrote: > Hello, > So I've got the Begin app compiling and linking under CMake, however it > cannot find resources during the loading process. I pointed the working > directory in Visual Studio to the begin/resources directory, but this does > not seem to help. I tried referencing the bjam scripts as well, but since I > am not familiar with bjam I had trouble finding anything helpful. > > Can anyone give me some pointers? It is trying to find *glossary.xstr*. > |
|
From: Foster B. <fbr...@ad...> - 2009-06-01 16:51:38
|
On 30/05/09 12:34 PM, "Robert Dailey" <rcd...@gm...> wrote: > So I found out that adobe::find_resource() is being used to try to find > glossary.xstr. However, it only uses the root_path() for searching, which > isn't very flexible at all. How about making this function check a few more > places, in particular the working directory. Also, it would be a nice feature > to be able to specify a list of resource directories at the command line for > the begin app and have those be used for searching for resources, amongst > other obvious paths. The resource system in APL definitely lacks a more robust design; that being said, it is not used outside of Adobe Begin, so it's limited use has prevented further development of it. If you would like to improve it to better suit your needs, please feel free. How would you specify additional resource directories at the command line for Adobe Begin? The idea is that it's a double-clickable app, so I'm missing something here. > Doing this will prevent me from having to copy files around via CMake to > ensure that resources can be found. I can make these changes myself, if you > guys think it would be a good idea. I'm leaning more towards the command-line > parameter approach for specifying resource directories. If the resource directories you are interested in finding (e.g., the working directory or a common a preferences directory) can be derived from the OS (even if it's an OS-specific routine) then I'd think it would be better for the app to discover those directories automatically. There are platform-specific source directories for both Mac and Windows that the resource system would be able to tap into to solve this problem. > Another comment: The root_path() is basically a singleton, and not thread safe > at all. It would be ideal to make > resource "hints" a concept, possibly create a new class called ResourceReposit > ory, which can be given directory hints (where to find resources) and can be u > sed to obtain resources. Can you describe a use case where one thread would want a different set of resource directories than another? As for the thread safety issue, it shouldn't be too hard to turn root_path into a threadsafe type. As I said before, there's no concerted effort going on inside Adobe to improve APL. Occasionally bug fixes will be made and utility code shuffled around to make it more accessible to external sources, but most of it is unused. You're welcome to work out ways of improving it. Blessings, Foster > On Fri, May 29, 2009 at 7:56 PM, Robert Dailey <rcd...@gm...> wrote: >> Hello, >> >> So I've got the Begin app compiling and linking under CMake, however it >> cannot >> find resources during the loading process. I pointed the working directory in >> Visual Studio to the begin/resources directory, but this does not seem to >> help. I tried referencing the bjam scripts as well, but since I am not >> familiar with bjam I had trouble finding anything helpful. >> >> Can anyone give me some pointers? It is trying to find glossary.xstr. > -- Foster T. Brereton <ἰχθύς>< Ro 3:21-26 Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Robert D. <rcd...@gm...> - 2009-06-01 18:32:57
|
On Mon, Jun 1, 2009 at 11:51 AM, Foster Brereton <fbr...@ad...> wrote: > > The resource system in APL definitely lacks a more robust design; that > being > said, it is not used outside of Adobe Begin, so it's limited use has > prevented further development of it. If you would like to improve it to > better suit your needs, please feel free. How would you specify additional > resource directories at the command line for Adobe Begin? The idea is that > it's a double-clickable app, so I'm missing something here. It is a unit test, correct? If so, it needs to be executed from the command line. Any other means of running the unit test, most usually, should be unsupported. This includes double-clicks. Unit testing, in my opinion, is normally automated through some form, and double clicking will never be necessary. > If the resource directories you are interested in finding (e.g., the > working > directory or a common a preferences directory) can be derived from the OS > (even if it's an OS-specific routine) then I'd think it would be better for > the app to discover those directories automatically. There are > platform-specific source directories for both Mac and Windows that the > resource system would be able to tap into to solve this problem. I completely agree. However, I apologize that I did not adequately explain what I was trying to say. Basically, this is why I called them "hints". In addition to typical assumptions you can make as far as where to search for resources (e.g. PATH, working directory, containing directory, etc) you would have another concept called "hints". These are user-specific paths that are not predictable and thus are specified manually to assist in finding resources. It simply gives the resource repository some extra places to look. > Can you describe a use case where one thread would want a different set of > resource directories than another? As for the thread safety issue, it > shouldn't be too hard to turn root_path into a threadsafe type. It's not that two threads would need a different set of resource directories than the other. The issue is more specific than that. If one thread tries to update the root directory while another is accessing that, you have your classic race condition. It doesn't matter if this use case is practical or not, the issue should not exist in general. However, as you've already clarified, APL is deprecated and so is this area of code. I am no longer concerned with it having this new information. > As I said before, there's no concerted effort going on inside Adobe to > improve APL. Occasionally bug fixes will be made and utility code shuffled > around to make it more accessible to external sources, but most of it is > unused. You're welcome to work out ways of improving it. Sorry, this has been a misunderstanding on my part. I was not aware that APL was essentially deprecated. I guess in that regard, I'm not really familiar with the roadmap for ASL/APL. The fact of the matter is, there will almost always be varying implementations for widgets between platforms. Having said that, I simply assumed APL represented those variations and would remain around for that reason. ASL seems like the abstractions to me (i.e. the widget concepts) and APL seems like the implementation of those concepts (i.e. how a widget is implemented on Windows or Linux). If this is not the case, I am interested in knowing where these implementations will be located in the long term. The only reason why I was commenting on the find_resource() method is because I was not aware it was deprecated, as I said before. Now that I know, I do not feel the need to improve it, since it is moot. It will be removed later on anyway. For now, copying the resources will work until APL is completely eliminated and a better approach to finding resources becomes available. What is the ideal way of locating resources? This seems like something outside of the scope of ASL. Is it up to the unit test as to how it wishes to access resources? Perhaps ASL asks for an EVE script through the means of an input stream? I have a lot to learn in this area. I jumped into CMake not thinking that I would have to become so familiar with ASL just yet. |
|
From: Foster B. <fbr...@ad...> - 2009-06-03 23:08:39
|
On 1/06/09 11:32 AM, "Robert Dailey" <rcd...@gm...> wrote: > On Mon, Jun 1, 2009 at 11:51 AM, Foster Brereton <fbr...@ad...> wrote: >> >> The resource system in APL definitely lacks a more robust design; that being >> said, it is not used outside of Adobe Begin, so it's limited use has >> prevented further development of it. If you would like to improve it to >> better suit your needs, please feel free. How would you specify additional >> resource directories at the command line for Adobe Begin? The idea is that >> it's a double-clickable app, so I'm missing something here. > > It is a unit test, correct? If so, it needs to be executed from the command > line. Any other means of running the unit test, most usually, should be > unsupported. This includes double-clicks. Unit testing, in my opinion, is > normally automated through some form, and double clicking will never be > necessary. Adobe Begin isn't a unit-test; it is a GUI front-end and editor for property model and layout library files. As such it doesn't meet the requirements of a command-line unit test. >> If the resource directories you are interested in finding (e.g., the working >> directory or a common a preferences directory) can be derived from the OS >> (even if it's an OS-specific routine) then I'd think it would be better for >> the app to discover those directories automatically. There are >> platform-specific source directories for both Mac and Windows that the >> resource system would be able to tap into to solve this problem. > > I completely agree. However, I apologize that I did not adequately explain > what I was trying to say. Basically, this is why I called them "hints". In > addition to typical assumptions you can make as far as where to search for > resources (e.g. PATH, working directory, containing directory, etc) you would > have another concept called "hints". These are user-specific paths that are > not predictable and thus are specified manually to assist in finding > resources. It simply gives the resource repository some extra places to look. Gotcha. That does clear things up as to what you meant. >> Can you describe a use case where one thread would want a different set of >> resource directories than another? As for the thread safety issue, it >> shouldn't be too hard to turn root_path into a threadsafe type. > > It's not that two threads would need a different set of resource directories > than the other. The issue is more specific than that. If one thread tries to > update the root directory while another is accessing that, you have your > classic race condition. It doesn't matter if this use case is practical or > not, the issue should not exist in general. However, as you've already > clarified, APL is deprecated and so is this area of code. I am no longer > concerned with it having this new information. OK. >> As I said before, there's no concerted effort going on inside Adobe to >> improve APL. Occasionally bug fixes will be made and utility code shuffled >> around to make it more accessible to external sources, but most of it is >> unused. You're welcome to work out ways of improving it. > > Sorry, this has been a misunderstanding on my part. I was not aware that APL > was essentially deprecated. I guess in that regard, I'm not really familiar > with the roadmap for ASL/APL. The fact of the matter is, there will almost > always be varying implementations for widgets between platforms. Having said > that, I simply assumed APL represented those variations and would remain > around for that reason. ASL seems like the abstractions to me (i.e. the widget > concepts) and APL seems like the implementation of those concepts (i.e. how a > widget is implemented on Windows or Linux). If this is not the case, I am > interested in knowing where these implementations will be located in the long > term. APL isn't essentially deprecated; it's just that there's no continuing development effort for the widget implementations therein. Internally Adobe products have their own widget frameworks we're using instead of APL's set, and externally there hasn't been any contributor who has stepped up to keep the APL widget set up to date. The code is still useful as the example it serves, but I wouldn't recommend relying upon the widget set as production-level code. That being said, there is still a lot of other utility code in APL that is immensely useful, which both internal and external parties to Adobe rely upon. > The only reason why I was commenting on the find_resource() method is because > I was not aware it was deprecated, as I said before. Now that I know, I do not > feel the need to improve it, since it is moot. It will be removed later on > anyway. For now, copying the resources will work until APL is completely > eliminated and a better approach to finding resources becomes available. The lack of development effort speaks more to the lack of volunteerism than the quality or longevity of the code. It's not coming out of APL anytime soon, it's just not being used. You're free to use it, and if you see improvements you'd like to make to it you're welcome to do so. Our only requirement at this point is that Adobe Begin and the APL unit tests continue to compile and run with at least the same level of functionality as they do now. > What is the ideal way of locating resources? This seems like something outside > of the scope of ASL. Is it up to the unit test as to how it wishes to access > resources? Perhaps ASL asks for an EVE script through the means of an input > stream? I have a lot to learn in this area. I jumped into CMake not thinking > that I would have to become so familiar with ASL just yet. For the unit tests any external information is provided to it via command line. Adobe Begin is a different beast, as I mentioned before. Blessings, Foster -- Foster T. Brereton <ἰχθύς>< Ro 3:21-26 Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Robert D. <rcd...@gm...> - 2009-06-04 00:48:48
|
On Wed, Jun 3, 2009 at 6:58 PM, Sean Parent <sea...@me...> wrote: > I would object to putting in support for searching above the folder > containing the executable - this is a potential security risk (a resource > can be replaced/overwritten without write access to the application > directory). > > Copying application resources into a "package" is a good thing. Good point. I had always agreed with this, it's just an interesting way of looking at my suggestion. I never thought of how it could be exploited for the worst. I think there is some miscommunication here. When I called the begin app a unit test, that's because I'm referring to the one in //adobe_platform_libraries/test/begin. When I ran this app, it was merely a dialog with a slider and an edit field. Nothing more. It didn't look like a "GUI front-end and editor for property model and layout library files ". Is there another begin app somewhere I am missing out on? Apologies for my confusion. There's also another thing I'm fairly confused about. And again, I do apologize, as this is getting slightly off topic, but bear with me if you would. Let's say that APL goes away, since that essentially seems like what it will do eventually. With just ASL around, how can it possibly be functional without any widget implementations? For example, if I have an interface for a Button widget, but no implementation for it for Windows, no button can be created. There needs to be Win32 code at *some level* in order for ASL to be even remotely useful. Either that, or the design philosophies I've been reading are completely misleading. Some detailed insight into this would be really helpful for me. If there are articles I can read, by all means please point me in the right direction. Thanks again to everyone for helping. |
|
From: Robert D. <rcd...@gm...> - 2009-06-04 01:00:41
|
On Wed, Jun 3, 2009 at 7:34 PM, Robert Dailey <rcd...@gm...> wrote: > On Wed, Jun 3, 2009 at 6:58 PM, Sean Parent <sea...@me...> wrote: > >> I would object to putting in support for searching above the folder >> containing the executable - this is a potential security risk (a resource >> can be replaced/overwritten without write access to the application >> directory). >> >> Copying application resources into a "package" is a good thing. > > > > Good point. I had always agreed with this, it's just an interesting way of looking at my suggestion. I never thought of how it could be exploited for the worst. > > > I think there is some miscommunication here. When I called the begin app a unit test, that's because I'm referring to the one in //adobe_platform_libraries/test/begin. When I ran this app, it was merely a dialog with a slider and an edit field. Nothing more. It didn't look like a "GUI > front-end and editor for property model and layout library files > ". Is there another begin app somewhere I am missing out on? Apologies for my confusion. > > There's also another thing I'm fairly confused about. And again, I do > apologize, as this is getting slightly off topic, but bear with me if you > would. Let's say that APL goes away, since that essentially seems like what > it will do eventually. With just ASL around, how can it possibly be > functional without any widget implementations? For example, if I have an > interface for a Button widget, but no implementation for it for Windows, no > button can be created. There needs to be Win32 code at *some level* in order > for ASL to be even remotely useful. Either that, or the design philosophies > I've been reading are completely misleading. Some detailed insight into this > would be really helpful for me. If there are articles I can read, by all > means please point me in the right direction. > > Thanks again to everyone for helping. > Update: I just downloaded the v1.0.42 release of ASL with the begin app for Windows, and I actually see all of the dialogs now. I understand what you mean now. I just find it odd that it is in the /test/ directory. I simply assumed those were for unit/integration tests. |
|
From: Robert D. <rcd...@gm...> - 2009-06-04 02:10:33
|
On Wed, Jun 3, 2009 at 8:33 PM, Sean Parent <sea...@me...> wrote: > There certainly needs to be some client code to integrate ASL into a widget > set - but that could be Win32, WPF, Cocoa, Carbon, GTK, Qt, Flash, HTML, or > whatever framework you happen to be using. Adobe has their own widget set > (if you lookup screenshots of our video apps you'll see it in existing > applications). The layout library and property model libraries are intended > to be generic components that can be integrated with whatever you are using. > Kind of like std::vector<> isn't useful unless you supply a type to it. > > I hope that folks will share their integrations (maybe Adobe will open > source their widget library at some point? ). > > We backed off from supporting the Win32 and Carbon APIs because MS is > pushing WPF, Apple is pushing Cocoa, and Adobe chose neither. > So you mean to say that out of the box, ASL won't create any widgets? I have to implement the widgets myself? That could take months, and isn't very practical. I thought the whole idea behind ASL was to be an alternative to frameworks like Qt and wxWidgets and provide a way, through a library, to create GUI applications portably. I'm either still confused or I'm just in a state of shock. So just to make sure I get this straight... basically, you're saying that I do the following to get an app up and running: - Download ASL - Create a button widget class, and implement it using Win32. - Now I can create a button in ASL If this is true, then ASL's only purpose in that example is to be a scripting language for widget layout. And correct me if I'm wrong, but WPF doesn't support C++. So I don't know what good bringing it up is. Since ASL is in C++, it kind of has to use Win32 if it plans on supporting Windows UI. I don't see any other choice. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X