On 16 Jan 2013, at 18:25, Alan Alpert <4163654...@gmail.com> wrote: > On Wed, Jan 16, 2013 at 5:16 AM, Mohamed Fawzi <fawzi.moha...@digia.com> > wrote: >> >> On 16 Jan 2013, at 10:54, Thomas Hartmann <thomas.hartm...@digia.com> wrote: >> >>> Hi, >>> [...] >>>> I assume the selected content is also in the app local dir, but you >>>> have a special way to access it without tripping the selector code. >>>> Note that selector code, at least in the QML engine, can't be strictly >>>> limited to the running app's local dir, because QML modules might want >>>> to use selection too (on files in their plugin local dir). >>> >>> Yes we identified this issue, too. >> >> The main reason we left it (and also a detailed selector definition) out >> is that as soon as you add libraries a problem comes in: >> selectors are global, and if you allow user defined selectors >> (which I am inclined to have), then one might have clashes >> (same selector name used in a different way) when using several libraries > > The only use case I can think of for libraries to define selectors is > to make them available in the application, like if a SystemInfo > library added a bluetooth selector if the device had bluetooth. This > usecase requires the selectors to be global. So long as libraries are > clear and upfront about the selectors they enable, application > developers can manage it fine themselves. Like we have with symbol > names in C++.
If you are using two components libraries, and both define highres, but the meaning (i.e. the dpi at which it should switch) is different then how do you use them together? > > -- > Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
