[Development] Qt6 and QCA
Hello, After reading thiago's tougths about the QRandomGenerator I wonder about the status of the Qt Cryptographic Architecture. From what I know it's not a Qt project but it's whidely used for applications that depend on cryptography and ssl, but not activelly maintained. There are plans to actually integrate the QCA into Qt as a module - or something similar? Best, Tomaz ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository request: HTTP server
On Fri, Oct 6, 2017 at 2:48 PM, Lars Knoll wrote: > Hi Fredrik, > > +1 for this one as well. Are you going to be the maintainer for the > module, or is it going to be someone else? > > Cheers, > Lars > > > On 6 Oct 2017, at 13:10, Fredrik de Vibe wrote: > > > > Hi all, > > > > We have recently been working on a research project looking into the > possibilities for creating a lightweight server component that can easily > enable Qt applications to serve over HTTP. We would like to make this work > public and therefore request a repository. > > > > This work is intended to continue as a research project, to explore > alternatives and reveal areas that need work, so it should be under qt-labs. > This is not something similar to what Tufao and Cutelyst are? Perhaps it would be nice to talk to them and see if they can share code. https://cutelyst.org/ https://github.com/vinipsmaker/tufao > > > Name of the project: Qt HTTP Server > > Responsible person: Fredrik de Vibe > > Gerrit user/email: fredrik.dev...@qt.io > > Desired repository name: qthttpserver > > > > > > -- > > Fredrik de Vibe > > Senior Manager, Qt Core and Network > > > > The Qt Company > > Sandakerveien 116 > > 0484 Oslo, Norway > > fredrik.dev...@qt.io > > http://qt.io/ > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using private API for qt-based library
On Tue, Sep 26, 2017 at 6:51 PM, Thiago Macieira wrote: > On terça-feira, 26 de setembro de 2017 09:28:25 PDT Fabrice Salvaire wrote: > > Le 25/09/2017 à 10:56, Viktor Engelmann a écrit : > > > On 25.09.2017 10:29, iman ahmadvand wrote: > > >> Hi every one. > > >> I'm developing a set of specialized opensource widgets in c++ (called > > >> MaterialWidgets which is google material design implementation) > > >> Now i want to use private API for this library to prevent re > > >> implementing a bunch of logics behind those widgets. > > >> > > >> What is your suggestion ? > > > > > > don't > > > > Sure, but in some particular cases, we have no choice when Qt don't > > expose the API > > You do have a choice. Multiple, even. The first and simplest: don't do what > you're trying to do. > > Second, you can also add public API to allow what you're asking. See my > other > email sent to the interest mailing list. > > The third option is to import the code you're developing into Qt. Then you > are > allowed to use the private API. > And this should be a theme, not a new widget set. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Configuration Generation from Schema
Greetings,
A *long* time ago I started trying to create a replacement for QSettings in
json, but if failed for the following reasons:
- Different Views on what it should accomplish - I envisioned the JSON as a
meta-language for generating the C++ code for the QSettings, while others
tougth I was using JSON as the settings definitions on disk
- Json has no notion of int / floating point, everything is floating point,
and so on the json file I had to add an entry for the type of the setting
for every setting, making that option quite verbose.
- Json is not the default configuration file for windows / mac / android /
ios, while usual unix has no default, that's a stopper per see, as some
projects should use the default on each system.
So I tried a different approach this time, creating a qml-like sintax for
the configuration file, a pre-processor that generates C++ code for
QSettings and it's easily used with Widgets / QML code,
It looks a bit like KConfigXT without the extras and written in something
less verbose than XML, and imo my approach also generates a better c++
class chain than KConfigXT (on KConfigXT all the preferences members are
"global" from within the main Preferences class, while on my they are
agreggated in subclasses).
It also provides a signal / slot for each setting, so a change on any
setting will change the QML component that interacts with it:
preferences.conf file:
#include
Preferences {
Window {
QColor color = "#FF"
}
}
QML usage:
Rectangle {
backgroundColor : preferences.window.color
}
onSomething {
preferences.window.color = "black"
}
C++ usage:
#include "genreated_preferences.h"
Preferences::self()->load();
connect(Preferences::window(), &Window::colorChanged, [=](const QColor& c)
{ setBackgroundColor(c});
Preferences::self()->window()->setColor( QColor("#010101") );
Preference::self()->sync();
the current code works (as in generates the correct c++ classes), there's
plenty of unittests with examples on how to write the configuration files,
and I tested all the compiled files against a simple application to be sure
there are no obvious bugs.
This was my first try at a C++ project that didn't used Qt so if there's
anything wrong there I'll fix, and please don't hit the developer :)
code currently is in https://github.com/tcanabrava/configuration-parser
If this is something that qt has interest on integrating I'll gladly change
everything on the project necessarely for that.
Regards,
Tomaz Canabrava
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution proposal, mainly server-side and QtWidgets-based
Just a bit of information, The subsurface app ( the one Linus started) uses qt on the server side too for our services. We currently use the tufao qt Web engine. Tomaz Em qui, 1 de out de 2015 10:44, Grégoire Barbier escreveu: > Le 01/10/2015 00:48, Jaroslaw Staniek a écrit : > > Hi Grégoire > > All of this looks interesting, and the web integration is just awesome > idea. > > We need more of Qt on the server! > > Thanks Jaroslaw ! > > I think that sharing the same model code for a web console and a desktop > (or phone) gui is very interesting, hence what I did (even though it > still needs work). > > And I would found convenient to git-push the same code on a Qt cloud > services' MAR instance hosting a web app, than the one in the > full-featured app. > > But since you are the only one having replied to my mail, maybe this is > not a so common need, or not the most important for many of us. > > And, apart from that, I wrote Qt server-side utilites because I wrote a > server using Qt, but when I searched for such frameworks, I found very > few Qt apps on the server side, I don't know if people don't write such > apps because they don't find Qt suited for that, because most people > think that Qt is just a gui toolkit, or because some tools are lacking. > I personnaly needed features present in QProcess and > QNetworkAccessManager, in a portable way, and an event loop. > > Qt is great on the server-side, to me. :-) > > -- > Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why can't QString use UTF-8 internally?
On Wed, Feb 11, 2015 at 2:20 PM, Guido Seifert wrote:
>
> Minor OT, but I am too curious... do you have an example?
> Are there really cases were turning lower case into upper case or
> vice versa changes the length of a string?
>
Yes, and he already said such example, ß becomes SS
>
> Guido
>
> > > std::string s("hello");
> > > std::transform(s.begin(), s.end(), s.begin(), ::toupper);
> > >
> > > and
> > > std::transform(s.begin(), s.end(), s.begin(), ::tolower);
> > >
> > > Not sure about the performance though
> >
> > That's flawed by construction. Uppercasing and lowercasing are string
> > operations, since it can change length, *especially* if you do it in
> UTF-8.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++ QML Interface thoughts
On Tue, Jan 20, 2015 at 3:32 PM, techabc wrote: > Is there any plans to complite QT QUICK for desktop as QWidgets as well? > It already is. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff wrote:
> On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote:
> > People, I'v read everything on the other two e-mails and I'v changed
> quite
> > a few things here and again I ask for some advice.
> >
> > What I'v done:
> >
> > QConfig / QConfigGroup / QConfigWatcher combo classes, to be used from
> the
> > user
> > QConfigIniBackend, to be used internally.
> >
> > QConfig:
> >
> >uses a 'global' QHash for different files
> in
> > a way that we don't destruct the info when the object is destroyed, but
> > reuses the JSON information stored, and parse it to the config object.
> >
> > it has a QConfigGroup 'global' value that can be acced directly via
> > .setValue and .value
>
> Why the global state? A QConfig should be valid for a single file and
> constructed on-demand. If you want to share stuff and keep it open, adding
> something like a KSharedConfig might be a good idea. But again, that is
> something that could/should be built on-top of QConfig (imo).
>
so I don't need to open a config file and parse it every time the user
created a QConfig object.
>
> > QConfig and QConfigGroup *does not* support setting a default value on
> the
> > getter, I know that this is used in a lot of places but this can cause
> > inconsistencies:
> >
> > Main.cpp
> >
> > QConfig c;
> > c.value("window-width", 800);
> >
> > MainWindow.cpp
> > c.value("window-width", 1200);
> >
> > so we must create a better way for that. for now, I simply removed the
> > possibility for that, we can only do
> >
> > c.value("window-width");
>
> And how do you check whether window-width was read or not? What do you
> return
> on error? A default-constructed value? What type does the value have for
> that
> matter?
>
> Imo, this makes this API extremely inconvenient. Yes it's possible to do an
> error, but that is life. You should only add such error-prevention stuff
> into
> the high-level schema stuff, not into QConfig itself.
>
> Without the ability to provide a default value, one can never figure out
> whether `c.value("some-int") == 0` means the value could not be read and a
> default should be used, or whether the value is 0.
>
Since I wanted to add schema-validation on the low level stuff, this
wouldn't be an issue,
'value couldn't be read' would cause an assert.
but I can postpone this for later.
> I plan to set the defaults via a schema-based file ( could be the
> KConfigXt
> > based, but I dislike having to edit XML by hand, so something more
> similar
> > to QML would be best ).
> > Any tougths on that?
>
> If you store JSON, maybe use JSON? The mapping will give you the default
> value
> and from there you get a type.
>
> {
> "foo" : 1,
> "bar" : { "lala": "string" }
> }
>
Yup - and I'm already working on a schema format conversor for json.
> > QConfigWatcher: created automatically via the .watcher() method on
> QConfig
> > and QConfigGroup
>
> It should be the other way around, imo. Also see below.
>
you are right. :)
>
> > Removed the need for pointers and references, implemented via DPointer
> and
> > move-semantics.
> >
> > Example usage:
> >
> > QConfig config;
> >
> > QConfigGroup window = config.group("window");
> > window.setValue("width", 800);
> > window.setValue("height", 600);
> > window.setValue("x", 100);
> > window.setValue("y",100);
> > window.setValue("opacity", 55);
> >
> > QConfigGroup font = config.group("fonts");
> > font.setValue("family", "san-serif");
> > font.setValue("pointSize", 9);
> > font.setValue("bold", true);
> > font.setValue("italic", true);
> >
> > QConfigGroup plasmoids = config.group("plasmoids");
> > for(int i = 0; i < 5; i++){
> > QConfigGroup plasmoid = plasmoids.group(QString::number(i));
> > plasmoid.setValue("name", "name_" + QString::number(i));
> > plasmoid.setValue("width", rand() % 100 + 100);
> > plasmoid.setValue("value", rand() % 100 + 100);
> > }
> >
> > connect(plasmoids.watcher(), SIGNAL(changed(QConfigGroup)), this,
> > SLOT(plasmoidsChanged(QConfigG
[Development] QConfig update.
People, I'v read everything on the other two e-mails and I'v changed quite
a few things here and again I ask for some advice.
What I'v done:
QConfig / QConfigGroup / QConfigWatcher combo classes, to be used from the
user
QConfigIniBackend, to be used internally.
QConfig:
uses a 'global' QHash for different files in
a way that we don't destruct the info when the object is destroyed, but
reuses the JSON information stored, and parse it to the config object.
it has a QConfigGroup 'global' value that can be acced directly via
.setValue and .value
QConfig and QConfigGroup *does not* support setting a default value on the
getter, I know that this is used in a lot of places but this can cause
inconsistencies:
Main.cpp
QConfig c;
c.value("window-width", 800);
MainWindow.cpp
c.value("window-width", 1200);
so we must create a better way for that. for now, I simply removed the
possibility for that, we can only do
c.value("window-width");
I plan to set the defaults via a schema-based file ( could be the KConfigXt
based, but I dislike having to edit XML by hand, so something more similar
to QML would be best ).
Any tougths on that?
QConfigWatcher: created automatically via the .watcher() method on QConfig
and QConfigGroup
Removed the need for pointers and references, implemented via DPointer and
move-semantics.
Example usage:
QConfig config;
QConfigGroup window = config.group("window");
window.setValue("width", 800);
window.setValue("height", 600);
window.setValue("x", 100);
window.setValue("y",100);
window.setValue("opacity", 55);
QConfigGroup font = config.group("fonts");
font.setValue("family", "san-serif");
font.setValue("pointSize", 9);
font.setValue("bold", true);
font.setValue("italic", true);
QConfigGroup plasmoids = config.group("plasmoids");
for(int i = 0; i < 5; i++){
QConfigGroup plasmoid = plasmoids.group(QString::number(i));
plasmoid.setValue("name", "name_" + QString::number(i));
plasmoid.setValue("width", rand() % 100 + 100);
plasmoid.setValue("value", rand() % 100 + 100);
}
connect(plasmoids.watcher(), SIGNAL(changed(QConfigGroup)), this,
SLOT(plasmoidsChanged(QConfigGroup)));
config.sync();
TODO, but only after this part gets perfect, KconfigXT like automatic
creation of classes and structures based on a schema file.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 go. The > > rationale is just to provide a quick way to have an advanced settings > > editor. > > Please don't overengineer. Displaying all the configuration settings in a tree > or table is not something most applications do. Most will have dialogs for > configuration, so a nicer, schema-based config dialog generator would be welcome > in the future. > > Only a "registry editor" application would show all entries in a tree or > table. I was thinking about something like about:config of the Firefox browser or a debug mode to show the developers all the config three, actually. Ill redo this part and create a config model outside. Tomaz > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 literals.
>
> const QLatin1String SettingsGroup("blah");
> const QLatin1String WidthKey("width");
It's not, as a string is not group aware.
> KConfig c;
> KConfigGroup g = c.group(SettingsGroup);
> g.setValue(WidthKey, 10);
KConfigGroup other = c.group(OtherSettings)
Other.setValue(WrongKeyForThisGroup);
> // otherfile
> Kconfig c;
> KConfigGroup g = c.group(SettingsGroup);
> g.value(WidthKey);
>
>
> How do you intend to fix string literal typos? IMHO compile-time checks
are
> better than run-time checks in these cases.
They are much better, agreed, but I plan to add run time checks first since
its easier to do, and in the future add a new binary to check for settings
Inconsiatencies based on a schema.
> Cheers,
> Rafael
>
> --
> Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 that > exists elsewhere. You don't need to use QAbstractTableModel to make QConfig > work, so can you explain where it comes into place? 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 an advanced settings editor. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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, 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 is what tomaz copied to his api. > > > > > > To my knowledge, only the internals are horrible and could easily be > > > improved, speed wise. > > > > the api is also horrible. it's full of inconsistencies. it has some > > specifics that make a clean multi-backend implementation not fully > > feasible. the c'tor flags for cascading and other features are rather > > error-prone. also, the duality of KConfig vs. KSharedConfig makes no > > sense. > > There are some dark corners in the API - that is correct. But you usually > don't have to care about that. The API that one uses normally is pretty > good > and definitely better than having to manually use references or such. > That's > what I have in mind when I talk about the good API of KConfig :) > > > on a different matter, what do we do about config change notifications? > > i tend to a separate class, say: > > > > QConfigWatcher::QConfigWatcher(const QConfigGroup &group); > > Q_SIGNAL changed(const QString &key); > > > > then we can postpone the actual design and implementation. > > Yeah, I like that idea, similar to what one can do via > KSettings::Dispatcher, > just nicer. > I tougth about having a changed() signal on the QConfig / QConfigGroup classes, is the QConfigWatcher a better approach? > > Bye > -- > Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin > > Milian Wolff | milian.wo...@kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 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 is what tomaz copied to his api.
> >
> > (still sleeping, só I will write better latter) I used kconfig and I
> > tougth it was terrible to use, that why I came to thiago and hélio Castro
> > asking if I could try a new one.
> >
> > I'll read the emails on this thread and change the code accordingly.
>
> Please double-check the KConfig API and copy more of its behavior. Some of
> that stuff was also mentioned by Thiago, Bo and Kai:
>
> QConfig("identifier_or_filename"); // this should also be the root group
>
> config.setValue("bla", 123); // would set a global config value, with
> multiple
> overloads or template functions
>
> QConfigGroup group = config.group("something"); // smart handle with
> reference
> semantics
> group.readValue("blub", /* default value */); // read value in group, also
> overloads and/or template function
>
> foreach (QConfigGroup subGroup, group.groups()) // or similar
>qDebug() << subGroup.name();
>
> I still think that KConfig, API-wise, is extremely convenient and haven't
> seen
> anything better so far. The internals and performance is a bit lacking, but
> usually not a problem and definitely not related to the API.
>
It's too error prone regarding typos.
// main.cpp
KConfig c;
KConfigGroup g = c.group("blah");
g.setValue("width", 10);
// otherfile
Kconfig c;
KConfigGroup g = c.group("blah");
g.value("widht"); // <- no error is issued, this is something that I wanna
have it fixed.
> --
> Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
>
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 the main class is QConfigGroup, > like > KConfigGroup. > Actually, I'm not - this was a design decision because I didn't tougth of a better way to do it - I didn't even looked at the KConfig api, and the last time I used it was the KConfigXT , years ago. :) > > > So is there any reason > > for writing something from scratch, instead of picking KConfig and adding > > the JSON cache feature on-top? Maybe I'm just missing some context or > > previous discussion on that matter? > > Licensing. > > Unless you're able to contact all the contributors to KConfig and convince > them > to relicense under the CLA for inclusion into Qt, then you have the time to > clean it up. David wanted the same for KStandardDirs, but he ended up > rewriting from scratch for QStandardPaths and the result was much cleaner. > I'm > expecting the same here. > > > Note that KConfig uses a pluggable format in the background, so adding > > registry or plist support is possible. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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, flags, value checking, > attributes for GUI form generation etc.). Each of the groups and > settings shared a common interface base. > > One feature that was very useful was the fact that we could > display/edit the settings hierarchy using a QAbstractItemModel in a > QTreeView. > > Do you intend to support the latter with your classes? > Yes - the QConfig is actually a QAbstractTableModel already. > > -- > Regards, > Bernhard Lindner > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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 point of view than it
> needs to be. But this might be because I don't know what the QConfig
> class does. If it's pretty much only a wrapper that holds the root and
> the file name, I would prefer that it's not exposed to the user.
>
> First possible way:
>
> QConfig config(optional filename);
>
Already works with filenames. :)
> config.setValue(...
> QConfigGroup window(config, "window");
>
Just changed to value semantics, got that out of the box. :)
> or
>
> QConfigGroup config(optional filename, optional QConfig)
>
> Thiago asked you not to use references. A design where you have an
> internally shared object that is the top config could work around this.
>
> But, as I said above, I'm not sure what your plans are for your QConfig
> class, and what the responsibilities of it are.
>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
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. > > > actually, it has proven horrible and is slated for a rewrite for a > decade. the only thing it does right is what tomaz copied to his api. (still sleeping, só I will write better latter) I used kconfig and I tougth it was terrible to use, that why I came to thiago and hélio Castro asking if I could try a new one. I'll read the emails on this thread and change the code accordingly. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 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'? )
>
> I think we should stick to .ini only. Access to the Windows registry
> should be
> done via QSettings or via a dedicated class.
>
> Mac people: do we need access to plist files?
>
> > Usage on code:
> >
> > Open a QConfig, get the root() group, fill some values,
> > if a value is changed a 'dirty' flag will be set on that particular
> group.
> > upon destruction it will generate a binary json representation to be kept
> > in memory
> > when .sync() it will forcefully sync on disk
> > when the QConfigCore object is destroyed, it will also flush on disk.
> >
> > Working code example of usage:
> >
> > int main(int argc, char *argv[])
> > {
> > QConfig config;
> >
> > QConfigGroup& root = config.root();
>
> Make sure a reference is not needed.
>
I can change the reference to a pointer - but the way I tougth of it
working, a reference or a pointer is needed: ( I may be wrong, of course );
QConfig config;
QConfigGroup *myGroup = config.root()->group("main")->group("secondary");
myGroup->setValue("testValue", 1);
should set the config.root() to dirty so I know that I need to update
something on the json.
> >
> > QConfigGroup& window = root.group("window");
> > window.setValue("width", 800);
> > window.setValue("height", 600);
> > window.setValue("x", 100);
> > window.setValue("y",100);
> > window.setValue("opacity", 55);
> >
> > QConfigGroup& font = root.group("fonts");
> > font.setValue("family", "san-serif");
> > font.setValue("pointSize", 9);
> > font.setValue("bold", true);
> > font.setValue("italic", true);
> >
> > QConfigGroup& plasmoids = root.group("plasmoids");
> > for(int i = 0; i < 5; i++){
> > QConfigGroup& plasmoid = plasmoids.group(QString::number(i));
> > plasmoid.setValue("name", "name_" + QString::number(i));
> > plasmoid.setValue("width", rand() % 100 + 100);
> > plasmoid.setValue("value", rand() % 100 + 100);
> > }
> > }
> >
> > Any tougths?
>
> Looks good!
>
I'll organize the code and the repository with meaningfull commits so you
guys can take a look and point me to the right direction.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QSettings refactor updates
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'? )
Cache format: binary json
If the json cache was created before the .ini, it will recreate the cache.
Internal format: I'v created a QConfigGroup / QConfig / QConfigCore set of
classes, that can be renamed if it better fits.
Usage on code:
Open a QConfig, get the root() group, fill some values,
if a value is changed a 'dirty' flag will be set on that particular group.
upon destruction it will generate a binary json representation to be kept
in memory
when .sync() it will forcefully sync on disk
when the QConfigCore object is destroyed, it will also flush on disk.
Working code example of usage:
int main(int argc, char *argv[])
{
QConfig config;
QConfigGroup& root = config.root();
QConfigGroup& window = root.group("window");
window.setValue("width", 800);
window.setValue("height", 600);
window.setValue("x", 100);
window.setValue("y",100);
window.setValue("opacity", 55);
QConfigGroup& font = root.group("fonts");
font.setValue("family", "san-serif");
font.setValue("pointSize", 9);
font.setValue("bold", true);
font.setValue("italic", true);
QConfigGroup& plasmoids = root.group("plasmoids");
for(int i = 0; i < 5; i++){
QConfigGroup& plasmoid = plasmoids.group(QString::number(i));
plasmoid.setValue("name", "name_" + QString::number(i));
plasmoid.setValue("width", rand() % 100 + 100);
plasmoid.setValue("value", rand() % 100 + 100);
}
}
Any tougths?
(missing: arrays and a better way to handle QClasses )
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Start of a refactor of the QSettings class based on QJson
On Thu, Sep 25, 2014 at 7:31 PM, Thiago Macieira
wrote:
> On Thursday 25 September 2014 16:33:12 Tomaz Canabrava wrote:
> > Long that that I have send this e-mail already, but better late than
> never.
> > In the Qt Develompent Summit I raised my hand to get one dirty thing
> done:
> >
> > The Settings.
> >
> > After a good while with negative time ( Real Work, KDE, Subsurface, and
> > other personal stuff ) I have finally had the time to start.
> >
> > For now, I'v implemented two things:
> >
> > Parsing from .ini to QJson
> > Saving from QJson to .ini
> >
> > Why .ini instead of json, since I'm doing a conversion and I coul'd
> simply
> > store the json file?
> >
> > .ini is better to humanreadability.
> > thiago asked me to do from ini to qjson
>
> Tomaz forgot a bit of the rationale for this.
>
> We want to have our cake and eat it too: we want both the ability to edit
> config files by hand and the speed of QJsonDocument. So we have a bunch of
> INI-
> style files that cascade their settings like the XDG Desktop file format,
> hopefully, are backwards compatible with QSettings, and can be edit by
> hand.
>
The one that I created is a bit different from the current QSettings file,
but that can be
changed. I'v used a less verbose approach -
current QSettings:
[Rootgroup]
sub/group/value1 = 1
sub/group/value2 = 2
current QConfig:
[RootGroup]
[RootGroup/sub]
[RootGroup/sub/group]
value1 = 1
value2 = 2
( and yes, this can change following you guys input.)
> Upon reading them, we save a cache of the settings in a binary JSON format.
>
That file is not hand-editable and we should not have to write a tool to
> manipulate it. The file needs to contain the names of the source INI files
> it is
> a cache of and their timestamps, so that hand editing of the sources
> invalidates the cache.
>
just implemented.
>
> It means, however, that saving the settings saves at least two files and
> cannot
> be done atomically. That's where QLockFile should come in handy.
>
> > After a Json tree is constructed, it's hard to modify it's contents:
> >
> > QJsonObject rootConfig;
> > rootConfig.insert("group1", QJsonObject());
> > rootConfig.insert("group2", QJsonObject());
> >
> > QJsonObject group1 = rootConfig.vaule("group1").toObject();
> > group1.insert("key1", 1);
> > rootConfig.insert("group1", group1);
> >
> > since I need to take the value, modify it, insert it back nested groups
> are
> > a pain to use,
> > because I would have to chain the removal / addtion of the parent group
> > untill I hit the rootGroup.
>
> Tomaz is planning to use the JSON classes as in-memory storage too, which
> may
> or may not be the best solution.
>
> I can think of three possibilities:
>
> 1) use QJsonDocument & family all the way, which means figuring out a
> solution
> to the above problem
>
> 2) use QJsonDocument only to read the on-disk cache, then keep an in-memory
> cache using a different storage mechanism (probably based on QVariantHash).
>
> 3) use a hybrid approach: use QJsonDocument for reading the cache and keep
> *that* cache in memory, but keep modifications separate, sync'ing the two
> storages only at the time the file actually gets saved.
>
> I think we will probably need #3 anyway so that we don't write *all* value
> entries to the the human-readable INI, only those that were modified from
> the
> original.
>
hm... will look into that.
>
> > what I plan to do, besides that:
> > - changed the config file from outside of the app, the app should reload
> > it's settings.
>
> Separate class, but yes, this is needed for GNOME- and OS X-style
> configuration
> mechanisms where changes are applied immediately upon change in the UI and
> propagate to all applications.
>
> I'm not sure we should Qt hide this on a platform config, but it's
> something we
> should think about.
>
> > - compile-time check of typos in keys based on a schema ( and not
> runtime. )
>
> Leave schema for a second version and focus on getting the storage right
> first.
>
> > the *temporary* repo with the *temporary and somewhat broken* code:
> > github.com:tcanabrava/QConfigNG
>
> https://github.com/tcanabrava/QConfigNG
>
> We can't it access via SSH because we're not you.
>
I didn't send the ssh, there's an https download link too.
git clone https://github.com/tcanabrava/QConfigNG.git
The changes that I sayd I did here are not there yet - for I am still
cleaning the code.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Start of a refactor of the QSettings class based on QJson
On Thu, Sep 25, 2014 at 6:51 PM, Jeremy wrote:
>
> On 5September2014, at 12:33, Tomaz Canabrava wrote:
>
> > Long that that I have send this e-mail already, but better late than
> never.
> > In the Qt Develompent Summit I raised my hand to get one dirty thing
> done:
> >
> > The Settings.
> >
>
> The general idea appeals to me.
>
>
> > After a good while with negative time ( Real Work, KDE, Subsurface, and
> other personal stuff ) I have finally had the time to start.
> >
> > For now, I'v implemented two things:
> >
> > Parsing from .ini to QJson
> > Saving from QJson to .ini
> >
> > Why .ini instead of json, since I'm doing a conversion and I coul'd
> simply store the json file?
> >
> > .ini is better to humanreadability.
> > thiago asked me to do from ini to qjson
>
>
> Binary compatibility requires that QSettings for 5.x continue to handle
> .ini files for all existing functions. Adding json for 5.5 should be fine.
>
I think we are talking different things here. the settings would continue
to be in .ini format, the json would be used as binary -cache ( disk and
memory ).
>
>
> >
> > Issues:
> >
> > After a Json tree is constructed, it's hard to modify it's contents:
> >
> > QJsonObject rootConfig;
> > rootConfig.insert("group1", QJsonObject());
> > rootConfig.insert("group2", QJsonObject());
> >
> > QJsonObject group1 = rootConfig.vaule("group1").toObject();
> > group1.insert("key1", 1);
> > rootConfig.insert("group1", group1);
> >
> > since I need to take the value, modify it, insert it back nested groups
> are a pain to use,
> > because I would have to chain the removal / addtion of the parent group
> untill I hit the rootGroup.
> >
>
> QJsonDocument doc = QJsonDocument::fromJson("{ \"name\": \"object\"}");
> QJsonObject obj = doc.object();
> QJsonValueRef ref = obj["name”];
> ref = "object2”;
> doc.setObject(obj);
>
QJsonObject obj = doc.object();
QJsonValueRef ref = obj["group1"];
QJsonObject groupObject = ref.toObject(); // <- lost reference.
QJsonValueRef ref2 = groupObject["group2];
QJsonObject groupObject2 = ref2.toObject(); << - again, lost reference.
groupObject2.add("key", object2);
and that's the issue.
>
>
> > what I plan to do, besides that:
> > - changed the config file from outside of the app, the app should reload
> it's settings.
>
>
> What’s the intended change detection mechanism? If it’s a file change,
> there’s the issue of incomplete updates to handle. I suppose it could
> ignore anything other than an valid JSON, empty files, and deleted files
> under the theory that edits of a single entry are less likely to produce
> valid interim results.
>
It will be a .ini file, so invalid json is a non issue, the others are, but
first I need to find a way to work around the other issue that I described.
> Will changes be announced at the document level, or more fine grained? I
> think anything beyond the document level is asking for trouble.
>
Document level.
>
> > - compile-time check of typos in keys based on a schema ( and not
> runtime. )
> >
> > Help is appreciated, and comments welcome.
> >
> > the *temporary* repo with the *temporary and somewhat broken* code:
> > github.com:tcanabrava/QConfigNG
> >
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Start of a refactor of the QSettings class based on QJson
On Fri, Sep 26, 2014 at 8:53 AM, Tor Arne Vestbø wrote: > On 26/09/14 00:31, Thiago Macieira wrote: > > >> since I need to take the value, modify it, insert it back nested groups > are > >> a pain to use, > >> because I would have to chain the removal / addtion of the parent group > >> untill I hit the rootGroup. > > This is a general issue with QtJson (and Qt), we don't seem to have an > easy-to-modify structure for data like this (as far as I can tell). > > Wish I could do: > >rootConfig["foo"] = 1; >rootConfig["bar"]["baz"] = 5; >QJsonObject biz = rootConfig["biz"]; >biz["buz"] = 6; > That would be perfect. > etc. > > tor arne > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Start of a refactor of the QSettings class based on QJson
Long that that I have send this e-mail already, but better late than never.
In the Qt Develompent Summit I raised my hand to get one dirty thing done:
The Settings.
After a good while with negative time ( Real Work, KDE, Subsurface, and
other personal stuff ) I have finally had the time to start.
For now, I'v implemented two things:
Parsing from .ini to QJson
Saving from QJson to .ini
Why .ini instead of json, since I'm doing a conversion and I coul'd simply
store the json file?
.ini is better to humanreadability.
thiago asked me to do from ini to qjson
Issues:
After a Json tree is constructed, it's hard to modify it's contents:
QJsonObject rootConfig;
rootConfig.insert("group1", QJsonObject());
rootConfig.insert("group2", QJsonObject());
QJsonObject group1 = rootConfig.vaule("group1").toObject();
group1.insert("key1", 1);
rootConfig.insert("group1", group1);
since I need to take the value, modify it, insert it back nested groups are
a pain to use,
because I would have to chain the removal / addtion of the parent group
untill I hit the rootGroup.
what I plan to do, besides that:
- changed the config file from outside of the app, the app should reload
it's settings.
- compile-time check of typos in keys based on a schema ( and not runtime. )
Help is appreciated, and comments welcome.
the *temporary* repo with the *temporary and somewhat broken* code:
github.com:tcanabrava/QConfigNG
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
