Blog | I'm available for programming contributions. C & Python.
Intel Core i7 920 | EVGA x58 SLI | NVidia GeForce 8600 GT | WD 500GB HDD | Corsair XMS3 3GB | Ubuntu 9.04
That explains a lot. Thanks.
The icon is in there now.I'll work on that. I'm a bit surprised, though, that e17 doesn't support SVG. Perhaps it's showing its age.
Thanks I added it to my main branch. LaRoza, my branch has some things for merging into trunk. Also, you can take just revision 62 and merge it into 1.0 to get the updated translation.We need it to install the .png files as well. When it can do that, it will be ready I guess.Is 1.0.2 ready for release now? The launchsysres script will workaround the bug you mentioned, and it's in 1.0.
Sorry for not updating, I've created a new branch sysres/gtk-frontend-1.0 on which I will aim to adress the problems with the gtk interface.
I should get time to work on it today in the weekend.
Don't peach linux. Melon it!
Ok, I have the branch I was working on as ~evigo/sysres/design and marked it as "Merged". I don't think to do any much work there.
I also reverted for historical reasons. It seems that when marking as "merged" the best practice is to leave things as they were... Think of a "closed" branch.
Now I'll focus a bit on the GTK+ frontend and see what's happening.
Has anyone tried to bug Canonical and see if this, or something like this could be in the default installations of *ubuntu?
Is that reasonable or a long shot?
I've built packages now for 1.0.2 (attached). The requisite changes should be merged into 1.0 from ~scott.severance/sysres/mssever. In the process, I discovered that we need to dynamically set the version number from either the build script or the installer. The .deb for 1.0.1 probably incorrectly reports the version as 1.0. 1.0.2 is correct, but only because I manually fixed it.
Please, let's make the this the last release of the 1.0 series, and base 1.1 off trunk. The version issue would be solved more simply if I didn't have to find an automated solution that will work for both trunk and 1.0, since they've diverged so much.
I also discovered another bug: In 1.0.2, making a restore point with -- in the name now fails silently. It shouldn't fail, and nothing should ever fail silently. I can't test in trunk, since trunk is currently broken (can't load any interface), and I haven't investigated as to the cause. Regardless of the cause, we need to re-think our exception handling. The ImportError is getting caught and the message "You must have Py(GTK|Qt) installed" is printed, even though the ImportError is definitely not related to pygtk or pyqt.
I didn't realize that anyone used Nautilus while programming.
I think it would be good, but IMHO we have a way to go. The GUIs don't follow the HIG, and sysres isn't sufficiently comprehensive or automatic. Installing a script in /etc/cron.weekly would go a long way toward solving the automatic problem, but to be sufficiently comprehensive would require a lot of thought about what exactly should be restored by default and what shouldn't. Also, how should we handle conflicts?
very good idea, i would like it if it could back up the init scripts , basicaly theses folders /etc/rc*.d
Desktop:i7 875k|4gb OCZ platinum ddr3 2000|Evga P55 LE mobo|OCZ RevoDrive 50gb|ATI 5850 Black Edition|Silverstone FT02|corsair tx650
Portable: 13" Macbook Pro 2.8ghz i7 16gb RAM | Asus EEE TF101 | Samsung Galaxy S2
Not for a while, no. I know OzOS is considering it, once I give them the green light that the release is ready.
I don't know what you mean. The version is in SystemRestore/Constants/__init__.py
If it works we will. 1.0.x should work, even if the code isn't the best.Please, let's make the this the last release of the 1.0 series, and base 1.1 off trunk. The version issue would be solved more simply if I didn't have to find an automated solution that will work for both trunk and 1.0, since they've diverged so much.
It isn't a bug. It is a kludge. It doesn't fail either, it changes them to __.I also discovered another bug: In 1.0.2, making a restore point with -- in the name now fails silently. It shouldn't fail, and nothing should ever fail silently. I can't test in trunk, since trunk is currently broken (can't load any interface), and I haven't investigated as to the cause. Regardless of the cause, we need to re-think our exception handling. The ImportError is getting caught and the message "You must have Py(GTK|Qt) installed" is printed, even though the ImportError is definitely not related to pygtk or pyqt.
Trunk's interfaces are expected to be broken, except for the CLI one.
I didn't realise anyone used Nautilus.I didn't realize that anyone used Nautilus while programming.
Conflicts with what?Also, how should we handle conflicts?
Bookmarks