On Monday 20 October 2014 14:26:17 Simon Hausmann wrote:
> > Should be completely transparent and orthogonal. The data types supported
> > by the front-end should not be affected by whatever it uses for caching.
> Ah, so that means custom types (types other than what QJson supports) will
> be conve
On Monday 20. October 2014 20.11.20 Thiago Macieira wrote:
> On Monday 20 October 2014 08:36:17 Simon Hausmann wrote:
> > On Monday 20. October 2014 07.06.00 Thiago Macieira wrote:
> > > On Sunday 19 October 2014 22:39:42 Branislav Katreniak wrote:
> > > > > Cache format: binary json
> > > >
> > >
On Monday 20 October 2014 08:36:17 Simon Hausmann wrote:
> On Monday 20. October 2014 07.06.00 Thiago Macieira wrote:
> > On Sunday 19 October 2014 22:39:42 Branislav Katreniak wrote:
> > > > Cache format: binary json
> > >
> > > You use json internally as cache. What is the motivation to introduc
On Monday 20. October 2014 07.06.00 Thiago Macieira wrote:
> On Sunday 19 October 2014 22:39:42 Branislav Katreniak wrote:
> > > Cache format: binary json
> >
> > You use json internally as cache. What is the motivation to introduce
> > new classes with similar API like QJson classes?
>
> It's an
On Sunday 19 October 2014 22:39:42 Branislav Katreniak wrote:
> > Cache format: binary json
>
> You use json internally as cache. What is the motivation to introduce
> new classes with similar API like QJson classes?
It's an implementation detail because the binary json loading and parsing is
ex
> Cache format: binary json
You use json internally as cache. What is the motivation to introduce
new classes with similar API like QJson classes?
Is the implicit shared semantics not suitable for this use case? Can
it be addressed in QJson classes directly?
If Qt gets some type safe wrappers ab
On 13.10.2014 13:46, André Somers wrote:
Milian Wolff schreef op 11-10-2014 16:44:
On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:
On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
Em 10/10/2014 06:18, "Oswald Buddenhagen
On Oct 13, 2014, at 10:30 AM, Morten Johan Sørvig
wrote:
>
>> On 10 Oct 2014, at 13:27, Ziller Eike wrote:
>>
>>
>> On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig
>> wrote:
>>
> Mac people: do we need access to plist files?
Plist is the format for application and
On Monday 13 October 2014 14:41:08 Thiago Macieira wrote:
> On Monday 13 October 2014 13:47:44 André Somers wrote:
> > Thiago Macieira schreef op 11-10-2014 10:25:
> > > On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote:
> > >> I tougth about having a changed() signal on the QConfig / QConfi
On Monday 13 October 2014 13:47:44 André Somers wrote:
> Thiago Macieira schreef op 11-10-2014 10:25:
> > On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote:
> >> I tougth about having a changed() signal on the QConfig / QConfigGroup
> >> classes, is the QConfigWatcher a better approach?
> >
On Monday 13 October 2014 13:46:21 André Somers wrote:
> Personally, I think that using string-based key-value pairs (whether the
> key has grouped semantics or not) and then manually casting the value to
> the needed everywhere you need it simply has no place in application
> code in all but th
Thiago Macieira schreef op 11-10-2014 10:25:
> On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote:
>> I tougth about having a changed() signal on the QConfig / QConfigGroup
>> classes, is the QConfigWatcher a better approach?
> Put it in a separate class. QConfig (Group) should not be a QObje
Milian Wolff schreef op 11-10-2014 16:44:
> On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:
>> On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
>>> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
Em 10/10/2014 06:18, "Oswald Buddenhagen" <
oswald.buddenha...@
> On 10 Oct 2014, at 13:27, Ziller Eike wrote:
>
>
> On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig
> wrote:
>
>>>
Mac people: do we need access to plist files?
>>>
>>> Plist is the format for application and other settings on OS X, and there
>>> are native tools for nicely editin
On Oct 10, 2014, at 8:16 PM, Adam Light wrote:
>
>
> On Fri, Oct 10, 2014 at 7:25 AM, Ziller Eike
> wrote:
>
> On Oct 10, 2014, at 3:37 PM, Adam Light wrote:
>
> > On the flip side, our large Qt application runs on Mac and Windows and
> > we're intentionally using QSettings with INI form
On Saturday 11 October 2014 11:39:40 Tomaz Canabrava wrote:
> Em 11/10/2014 11:35, "Thiago Macieira" escreveu:
> > On Saturday 11 October 2014 09:01:52 Tomaz Canabrava wrote:
> > > True, I dont need it to make things work, but I need it in case I wanna
> > > show them inside a qtreeview.
> > >
>
On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:
> On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
> > On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
> > > Em 10/10/2014 06:18, "Oswald Buddenhagen" <
> > >
> > > oswald.buddenha...@theqtcompany.com> escreveu:
> > > > On Fr
Em 11/10/2014 11:35, "Thiago Macieira" escreveu:
>
> On Saturday 11 October 2014 09:01:52 Tomaz Canabrava wrote:
> > True, I dont need it to make things work, but I need it in case I wanna
> > show them inside a qtreeview.
> >
> > I can split it into a QConfigTrreModel if you think its the way to
On Saturday 11 October 2014 09:01:52 Tomaz Canabrava wrote:
> True, I dont need it to make things work, but I need it in case I wanna
> show them inside a qtreeview.
>
> I can split it into a QConfigTrreModel if you think its the way to go. The
> rationale is just to provide a quick way to have a
Em 11/10/2014 09:20, "Rafael Roquetto" escreveu:
>
> On Fri, Oct 10, 2014 at 09:26:11PM -0300, Tomaz Canabrava wrote:
> > On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff
wrote:
> >
>
> >
> > It's too error prone regarding typos.
>
> This is easily solved by using constants instead of string litera
On Fri, Oct 10, 2014 at 09:26:11PM -0300, Tomaz Canabrava wrote:
> On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
>
>
> It's too error prone regarding typos.
This is easily solved by using constants instead of string literals.
const QLatin1String SettingsGroup("blah");
const QLatin1St
Em 11/10/2014 05:24, "Thiago Macieira" escreveu:
>
> On Friday 10 October 2014 21:22:34 Tomaz Canabrava wrote:
> > Yes - the QConfig is actually a QAbstractTableModel already.
>
> Sorry, can you explain this a little more?
>
> A Model is a standardised way for the Views classes to access a storage
On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote:
> I tougth about having a changed() signal on the QConfig / QConfigGroup
> classes, is the QConfigWatcher a better approach?
Put it in a separate class. QConfig (Group) should not be a QObject.
--
Thiago Macieira - thiago.macieira (AT) in
On Friday 10 October 2014 21:22:34 Tomaz Canabrava wrote:
> Yes - the QConfig is actually a QAbstractTableModel already.
Sorry, can you explain this a little more?
A Model is a standardised way for the Views classes to access a storage that
exists elsewhere. You don't need to use QAbstractTableM
On Fri, Oct 10, 2014 at 8:31 AM, Milian Wolff wrote:
> On Friday 10 October 2014 13:21:22 Oswald Buddenhagen wrote:
> > On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote:
> > > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote:
> > > > On Fri, Oct 10, 2014 at 11:07:52AM +0200
On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
> > Em 10/10/2014 06:18, "Oswald Buddenhagen" <
> >
> > oswald.buddenha...@theqtcompany.com> escreveu:
> > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > > may I
On Fri, Oct 10, 2014 at 6:24 AM, Thiago Macieira
wrote:
> On Friday 10 October 2014 11:07:52 Milian Wolff wrote:
> > may I ask why you don't simply copy KConfig? It's API design has proven
> to
> > be extremely versatile and efficient over the years.
>
> He is copying KConfig's API. That's why th
On Fri, Oct 10, 2014 at 3:50 AM, wrote:
> I once programmed a class hierarchy targeting the same features (and
> much more). It consited of settings group objects and settings object
> ordered in a tree hierarchy. That hierarchy was much more complex
> (having templated settings, units, limits, f
Hey,
On Fri, Oct 10, 2014 at 3:37 AM, Bo Thorsen wrote:
> Hi Tomaz,
>
> Den 10-10-2014 kl. 00:43 skrev Tomaz Canabrava:
> > QConfig config;
> > QConfigGroup& root = config.root();
> > QConfigGroup& window = root.group("window");
>
> This looks a bit more complicated from the user
On Fri, Oct 10, 2014 at 7:25 AM, Ziller Eike
wrote:
>
> On Oct 10, 2014, at 3:37 PM, Adam Light wrote:
>
> > On the flip side, our large Qt application runs on Mac and Windows and
> we're intentionally using QSettings with INI format on both platforms for
> consistency. Since the storage of sett
On Oct 10, 2014, at 3:37 PM, Adam Light wrote:
>> On Fri, Oct 10, 2014 at 4:27 AM, Ziller Eike
>> wrote:
>>
>> On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig
>> wrote:
>>
>> >>
>> >>> Mac people: do we need access to plist files?
>> >>
>> >> Plist is the format for application and other
On Fri, Oct 10, 2014 at 4:27 AM, Ziller Eike
wrote:
>
> On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig
> wrote:
>
> >>
> >>> Mac people: do we need access to plist files?
> >>
> >> Plist is the format for application and other settings on OS X, and
> there are native tools for nicely editing
On Friday 10 October 2014 13:21:22 Oswald Buddenhagen wrote:
> On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote:
> > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote:
> > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > > may I ask why you don't simply co
On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig
wrote:
>>
>>> Mac people: do we need access to plist files?
>>
>> Plist is the format for application and other settings on OS X, and there
>> are native tools for nicely editing these. Ini is highly alien on OS X.
>> So, I’d answer yes.
>
>
On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote:
> On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote:
> > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > may I ask why you don't simply copy KConfig? It's API design has
> > > proven to be extremely versatil
On 10-Oct-14 11:48, Morten Johan Sørvig wrote:
> I see this as two separate use cases:
> 1) Cross-platform API for managing application settings.
> 2) API for reading native settings, following the conventions of the platform
>
> To what degree was QSettings successful in combining these? Focusing
>
>> Mac people: do we need access to plist files?
>
> Plist is the format for application and other settings on OS X, and there are
> native tools for nicely editing these. Ini is highly alien on OS X.
> So, I’d answer yes.
On the other hand, git uses the ini file format for the config files a
On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
> Em 10/10/2014 06:18, "Oswald Buddenhagen" <
>
> oswald.buddenha...@theqtcompany.com> escreveu:
> > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > may I ask why you don't simply copy KConfig? It's API design has
> > >
On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote:
> On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > may I ask why you don't simply copy KConfig? It's API design has
> > proven to be extremely versatile and efficient over the years.
>
> actually, it has proven horrible
On Friday 10 October 2014 11:07:52 Milian Wolff wrote:
> may I ask why you don't simply copy KConfig? It's API design has proven to
> be extremely versatile and efficient over the years.
He is copying KConfig's API. That's why the main class is QConfigGroup, like
KConfigGroup.
> So is there any
Em 10/10/2014 06:18, "Oswald Buddenhagen" <
oswald.buddenha...@theqtcompany.com> escreveu:
>
> On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > may I ask why you don't simply copy KConfig? It's API design has
> > proven to be extremely versatile and efficient over the years.
> >
>
On Friday 10 October 2014 06:47:39 Ziller Eike wrote:
> I think it would not be good to create a new API for settings, and
> simultaneously force us to keep the old API because the new API doesn’t
> cover the old use cases. So, if Windows registry access should not be done
> through the new setting
On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> may I ask why you don't simply copy KConfig? It's API design has
> proven to be extremely versatile and efficient over the years.
>
actually, it has proven horrible and is slated for a rewrite for a
decade. the only thing it does right
On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
> Please be kind, this is the first step to contributing to qt that I'm
> trying. :)
>
> First, I'v implemented the rationale that thiago asked me to do on the
> other thread:
>
> Settings format: .ini ( current settings uses native form
I once programmed a class hierarchy targeting the same features (and
much more). It consited of settings group objects and settings object
ordered in a tree hierarchy. That hierarchy was much more complex
(having templated settings, units, limits, flags, value checking,
attributes for GUI f
> Cc: development@qt-project.org
> Subject: Re: [Development] QSettings refactor updates
>
>
>
> On Thu, Oct 9, 2014 at 7:48 PM, Thiago Macieira
> wrote:
>
>
> On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
> > Please be ki
On Oct 10, 2014, at 12:48 AM, Thiago Macieira wrote:
> On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
>> Please be kind, this is the first step to contributing to qt that I'm
>> trying. :)
>>
>> First, I'v implemented the rationale that thiago asked me to do on the
>> other thread:
Hi Tomaz,
Den 10-10-2014 kl. 00:43 skrev Tomaz Canabrava:
> QConfig config;
> QConfigGroup& root = config.root();
> QConfigGroup& window = root.group("window");
This looks a bit more complicated from the user point of view than it
needs to be. But this might be because I don't kno
On Thu, Oct 9, 2014 at 7:48 PM, Thiago Macieira
wrote:
> On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
> > Please be kind, this is the first step to contributing to qt that I'm
> > trying. :)
> >
> > First, I'v implemented the rationale that thiago asked me to do on the
> > other th
On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
> Please be kind, this is the first step to contributing to qt that I'm
> trying. :)
>
> First, I'v implemented the rationale that thiago asked me to do on the
> other thread:
>
> Settings format: .ini ( current settings uses native form
Please be kind, this is the first step to contributing to qt that I'm
trying. :)
First, I'v implemented the rationale that thiago asked me to do on the
other thread:
Settings format: .ini ( current settings uses native format, should I
implement that too or the reasoning here is 'be simple'? )
C
51 matches
Mail list logo
