Hi all, I already noticed that there are new users and potential developers joining our mailing list recently. Sorry I'm a little busy this week and I haven't reply every mail. Just say welcome for all newcomers here. I'll try to discuss with those potential developers about future development later when I got my job done.
To find other possibility for LXDE project especially for Google SoC event, I started some experiment to find out what else we can do. Here are two interesting new items: 1. battery plugin: I already have a prototype in lxpanel-plugins git repo based on upower. As mentioned by Marty Jack previously, upower is not API/ABI stable now. However, I made this with Vala. Since Vala has great built-in support for dbus, writing small applets which work with dbus becomes quite easy. In C this might requires 600 lines, but in Vala, only 100 might be required. I already finish the initial experiment, and after some integration this can become the new battery plugin. API/ABI stability is acceptable since developing dbus stuff with Vala is quite easy. We can fix it later easily if upower ABI/API changes later. Fixing this in Vala should be much easier than doing this in C. So, it's quite interesting. The generated C program although not very optimized, is efficient enough (when compared with other language bindings). And the generated binary size was also small. No additional dependency is needed. So Vala might be useful for LXDE in the future. 2. I also start experimenting with udisks to support basic volume management without requiring gvfs. However, gio module for this is very complex, requiring large amount of GObject handling, and it's hard to implement. With the aid of Vala, I expect this can be done in easier ways, too. However, during the experiment with Vala + udisks, I found some bugs of Vala and I'm currently discussing this issue on their mailing list. If this is solved, I might be able to do this with Vala. BTW, I have new ideas for lxrandr finally. I'm always thinking about how to improve this. Now I found the answer. LXRandR should save currently selected mode in config file, and tries to restore that on next login. If the monitors changed on next login, for example if external monitor was removed, it should fallback to default display mode, and prompt the user to select a new display mode again. Otherwise, just restore previous settings. In this way we can have a really useful monitor configuration tools. I also have new ideas for LXAppearance. If we enable loadable modules for LXAppearance, it's possible for other program to install modules for LXAppearance and extend its functionality. Then for example PCManFM can install a LXAppearance module, and then LXAppearance gains the ability to set desktop wallpaper and also have this option in the UI (added by the module). Then we can have a common place for all kinds of appearance settings. Another approach should be spliting lxappearance and make each part, the icon theme, gtk+ theme, and font settings, independent, and group them in a sub menu of "Preferences" menu. Then all kinds of appereance settings can be found under that sub menu. So users won't get confused whether he or she should launch lxappearance, pcmanfm2 --desktop-pref, or obconf. This is important for usability. Any comments? ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
