> On Nov. 4, 2013, 4:12 p.m., John Layt wrote: > > I've asked on the Qt Development list about Qt 5 Solaris support. I'm told > > it builds and works to some extent, and patches are welcome, but not > > without having been tested on a real Solaris build first, which I have no > > desire to do. I don't think much is required, Solaris uses the Olsen tz > > files, just with different patches and possibly a different zonetab layout, > > but I don't want to code blind. So we have two options, one is not worry > > about Solaris support for now, and if anyone (Ade?) complains then ask them > > to contribute upstream (with my help). The alternative is to keep the > > Solaris code in ktimezoned, including calls to return the current system > > time zone and the list of available time zones, and on other platforms just > > wrap the Qt calls. Opinions? > > John Layt wrote: > s/patches/paths
I'd like to reiterate the (imho) bigger issue here - there's no effort at all to have KF5 and/or PW2 running on Solaris (unlike the Windows effort), so I wouldn't push it (only) to the smallest component in the workspace, it makes no sense at this time. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review42961 ----------------------------------------------------------- On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > ----------------------------------------------------------- > > (Updated Oct. 22, 2013, 4:49 p.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > ------- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > ----- > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > ------- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
