Hi, Cestmir: I was thinking about either some toString / fromString methods on Setting<T>, or using QSettings inside (which is based on QVariant) Tomas: I wasn't thinking about the underlying layer too much yet. But it should probably be some text file as you're writing or a QSettings class. QSettings has the advantage that we won't have to care about any of the platform dependent stuff. K > Hi Kuba, > > templates are wonderful, but in terms of the settings manager class, > how will you save the settings there? Obviously, you will have to > provide a way of saving every possible type that will ever be called > by the templated functions. And you will have to know the type in > advance. And in the template function, how do you find out what type > is class T? RTTI? But that would mean that you have to forget about > primitive types ;-) > > I don't know. Maybe this is doable, but it seems to complicated to > me. I'd create a special method for every possible setting type. Yes, > there will be a lot of methods, but after all, that's why the > settings have a special class. > > Cestmir > > On Fri, Dec 2, 2011 at 2:42 AM, Kuba Marek <blue.cube@xxxxxxxxx> > wrote: > > > Hi, > > there's one thing we completely skipped in plugin API -- plugin > > settings. We were talking and thinking about this for the whole day > > on jabber and I've put something together. > > > > > > https://github.com/updraft/updraft/commit/9621592837afd9f59e4348e62fc917578d5942d1 > > > > What I was trying to achieve is to have both internal and > > usersettings. User settings should have GUI for different data > > types (int, string, filename, > > list, color picker and number with units (maybe not all of those)). > > > > Comments, please > > > > K > >