It’s been quite a while since my last update. I have not been all lazy, though. A while back I mentioned a Windows Eventlog Viewer, well, the problem is Xdialog. Xdialog has not been the best solution for several tools, due to it’s simplistic nature requiring multiple dialogs for pretty much everything. For the Eventlog Viewer it does not work at all. It’s impossible to create a GUI with Xdialog that is not a major pain in the ass.
I looked around for alternatives that would allow me to create a sophisticated GUI-Tool without a steep learning curve. I looked at c/c++ with different GUI Libraries like Edje or GTK but neither of them fullfilled my needs. I wasn’t too happy with c/c++ either, since it’s been ages since I last coded something in one of those languages. Java might have been an option, but, in my opinion, it is too big to ship on a lightweight disk.
Long story short: I ended up with Python and Qt. The Qt GUI builder allows to create a nice form in a few minutes and Python is not hard to learn. Python also offers a few features that may prove useful. The problem there is that I never worked with either before, therefore I’m not actually working on the Eventlog Viewer right now, but I’m porting simpler tools to python.
Again, there is something to show. I already ported netsetup (a fews things are still missing), it now uses a single window which makes correcting errors a lot easier.
So, Here’s another before—after comparison (click to enlarge):
I finally got around to do some work on GuARD, but I didn’t feel like debugging or writing documentation. For quite some time e16 annoyed me because it lacks configurability and several key features. Because of this I used wbar, since e16 didn’t bring its own app launcher. This is just one of the more obvious downsides.
I finally decided to upgrade to e17, which I use at my desktop for several years now. At first I was unsure if e17 would meet GuARD’s need for lightweight applications. It turns out that the memory usage is only a few MB higher than with e16, that was a nice surprise. As I am running GuARD mostly in a virtual machine, I could tweak the processing power as well. I gave it only one of my four cores and set the maximum usage to 50%. My host system is set up to run at 1200MHz unless the usage of the specific core rises above 60%. Since this will never be the case I gave GuARD effectively a 600MHz cpu. It still ran smoothly.
This encouraged me to remove wbar and use e17’s internal modules to get the job done. Namely using engage, which features a taskbar as well, a thing that was missing so far. Unfortunately I still didn’t find a way to display mounted filesystems in a more userfriendly way (allowing unmounting/ejecting). Still it is much easier and cleaner to configure things now, plus it looks better
Here are two before—after screenshots (click to enlarge):
Some time back, somebody told me that “it’s sad you can’t view the event log from a linux system”. Well, that’s what gave me the idea to include just this feature into GuARD. I looked around and found the Windows Event Log Viewer. It’s free to use, so that’s a plus, but distribution is prohibited.
Then I came along EVTX Parser. Which is quite nice, since it decodes the log to plain xml. It contains no viewer, though. That’s where the trouble starts.
I have several ways to go from here:
- write a GUI application from scratch to display the log
- write an xsl file to parse the log into html
- parse it with a shell script to some display format
The first one seems the nicest, the problem is, that my c/c++ skills are not that greatj I would have to resort to Java, but I don’t want to include all the extra bulk.
Using xsl seems to be the fastest way to do it. Sorting by category may be tough, though. I don’t think that’s an feature xsl can provide.
This leaves option number three. So far this is my favorite. It’s not much more work than creating an xsl file, but offers additional flexibility. Allowing me to split the log by category into several files and including a menu to choose the category. Maybe even using a relational database in the background to allow filters advanced sorts, etc. This may eat a bit ressources than necessary, though.
Of course I am open to other ideas. Just comment, if you have a better idea.
As you are looking at this post, you already know what the fuzz is about. The old scheme was a little too “Gentoo” for taste, especially the logo I used, since this is no official Gentoo project.
Also the Gentoo color scheme was a little to purplish for my taste… As well as for pretty much all people I forced to test GuARD.
Of course all artwork, both source and the final product actually used, in the svn have been updated as well.
I like the new look a lot better and I hope you will too. Enjoy!
I updated the Build Instructions. They are a bit cleaner now and include the complete instructions to build GuARD with aufs support.
I also added a few files to the svn. Everything required for using aufs is now online (one file was missing) and multi processor support for x86 is there, too.