The subject says it all: I'd like to get rid of the build keys.
Qt is the only toolkit I know that even has such a concept.
I don't know the exact details of why they were introduced in the first place,
but my guess is that it was due to the gcc 3.x ABI changes. The ABI has been
stable now
On 8/23/11 1:46 PM, ext Thiago Macieira thi...@kde.org wrote:
On Tuesday, 23 de August de 2011 11:16:08 lars.kn...@nokia.com wrote:
On 8/22/11 10:13 AM, ext Thiago Macieira thi...@kde.org wrote:
On Monday, 22 de August de 2011 00:13:42 John Layt wrote:
The methods have to be inline. We can't
On 8/23/11 1:55 PM, ext Thiago Macieira thi...@kde.org wrote:
On Tuesday, 23 de August de 2011 12:07:25 lars.kn...@nokia.com wrote:
Hi Thiago,
Full ack. I'm all for removing them. Are you willing to create the
change?
I suppose removing code isn't that hard... I'll do it after the QUrl
In the Getting rid of build keys thread, I wrote:
In light of that and the Mac App Store guidelines, I'd propose that on Mac
and Windows Qt never have global configuration. The configuration belongs
to the applications.
I'd like to propose we go one step further: Qt proper has *no* global
On Tuesday, 23 de August de 2011 14:07:46 Philip Ashmore wrote:
For example image file format support, you instantiate a mapping object that
looks up the registry and loads the implementor for that format if it's not
already loaded.
What registry are you talking about?
This is exactly the
Hello again
I'm inspired today
I'd like to propose that we mark QSettings as Done and move it to a separate
module, once the task I proposed in System and global settings and platform
plugins is complete.
If there are no global settings to use QSettings in, and there is no global
cache
On Tuesday, 23 de August de 2011 15:14:05 Thiago Macieira wrote:
The interface I propose for this is one front-end class in Qt, ostensibly
named QSystemConfiguration, with one or more static functions of the
signature:
static QVariant configuration(ConfigurationEntry entry);
where
23.08.2011, 17:28, Thiago Macieira thi...@kde.org:
On Tuesday, 23 de August de 2011 17:15:51 Konstantin Tokarev wrote:
23.08.2011, 17:14, Thiago Macieira thi...@kde.org:
Those settings should instead be provided by the platform plugin.
It won't work for lightweight environments
Can you
(Resending from the correct address, sorry Thiago :))
Hi,
On Tue, Aug 23, 2011 at 3:21 PM, Thiago Macieira thi...@kde.org wrote:
I'd like to propose that we mark QSettings as Done and move it to a separate
module, once the task I proposed in System and global settings and platform
plugins is
Hi,
Mobility's PS module (now part of the QtSystems module) provides a similar
functionality. And I'm currently doing some refactorings so simplify its
internals.
As of now, it uses registry on Windows, GConf on desktop Linux, ContextKit on
MeeGo.
Xizhi Zhu (Steven)
Software
On Tuesday 23 Aug 2011 13:41:47 Thiago Macieira wrote:
On Tuesday, 23 de August de 2011 14:00:02 lars.kn...@nokia.com wrote:
Uh... not exactly. Egyptian hyeroglyphs are part of Unicode and you might
run into them on webpages, so they should be properly laid out :-)
Not that most people
On Tuesday, 23 de August de 2011 21:49:39 John Layt wrote:
On Tuesday 23 Aug 2011 14:52:17 xizhi@nokia.com wrote:
Hi,
Mobility's PS module (now part of the QtSystems module) provides a
similar
functionality. And I'm currently doing some refactorings so simplify its
internals. As
On Tuesday, 23 de August de 2011 14:04:19 lars.kn...@nokia.com wrote:
Yes. Didn't we have some code to inspect elf headers? Could we maybe add
some data into a special elf section containing the info about the plugin?
That would at least solve it on elf systems.
Yes, we have that code. I think
Actually, how about something like this:
class QThread
{
// ...
public:
enum TimeUnit
{
Seconds,
Milliseconds,
Microseconds
};
void sleep(unsigned long time, TimeUnit units);
};
One could also envisage TimeUnit being in the Qt namespace rather than
14 matches
Mail list logo
