Stanislav Brabec wrote:
Jake Thebault-Spieker wrote:I've been working on coming up with ideas that Angstrom could use for it's Google Summer of Code application. These are the ideas I came up with, some of which were suggested by some people in the community(I think mickeyl, possibly others as well).The ideas are: First time install wizard/config wizard: -Walks through initial configuration/includes explanations -More Timezones -Pretty-fied to me more user friendly GUI package manager -One that functions(doesn't crash when trying to install more than one package) -Maybe w/ opkgThese two projects may be useful, but I guess that they are too minor projects for SoC. You can even grab parts of code from other projects.GUI installation tool(from NAND?) -For ease of install -Is this possible?Do you think extensions and improvement of u-boot to become generic installation tool?
I like this idea, again, I don't know enough about u-boot and the built-in bootloader(on the Z) to know if this is feasible/possible. I'm coming at this from the perspective of someone who doesn't know very much about the inner workings of the booting process in a Z.
GUI network config(smart) -Only configures interfaces it detects, non-generic -Easy for beginners, so as not to get confusedI guess we don't need yet another GUI tool on top of broken networking design. ifup/ifdown works well for static networks, but has no support for dynamic environments and there is nothing to replace it yet. Implementing following (straightforward for beginners) complex scenario needs much more than only GUI tool. It needs completely new design. Imagine that you are sitting on your desk and you want to continue with your work: 0. Ethernet cable was removed from the device. What to do now? (needs support for hotplug - already implemented) 1. Connect to private AP (implement searching of best fit default route) 2. Out out of signal? (implement signal monitoring) 3. Try to find any free Wi-Fi AP (implement WLAN network scanning) 4. If not found, fire up Bluetooth, check whether mobile phone and GSM signal are available (implement conditional actions and GSM modem support) 5. If yes, run pppd with on-demand GPRS networking (implement on demand networking and PPP support) 6. If not, go offline (implement Online/Offline signalling) It needs general discussion before starting to implement: - Should it be based on hal? And should be hal the technology for OE to go? If yes: - Should OE use upstream hal? - Should OE use cut-down hal version? - Should OE use uHAL (micro hal), small and device specific daemon providing device independent interface? - Should it duplicate design of NetworkManager (only one network active in one moment)? - If no: - Should it use script based ifup/ifdown? - Should it use D-Bus to notify users about change? - How to solve huge overkill of any actions (fork, [unswap,] start shell interpreter, start binary, change setup) There are several tools, which try to do the same, but none of them is really usable on PDA: - NetworkManager: Needs too much memory for mobile devices, has strong design limitation (only one network active in one moment) and cannot be the only networking solution provided for the device. - GPE networking setup: Helper for ifup/ifdown. Can be improved to work well for static setups. Has design limitation, which does not allow dynamic definitions. - WPA supplicant: Specialized application. Has D-Bus support to notify about changes in WLAN networks. Future design of wireless networking in kernel will require similar daemon running. Can be part of future design.Any feedback would be appreciated. I don't know if this is functionality Angstrom is looking for, but it's what I came up with.I can image two projects: - HAL/D-Bus integration for mobile devices - Make GPE really usable
Wow, you've put way more thought into this than I have, obviously. My question about the two options, or, more specifically the second one is this: Does making GPE usable really fall under the jurisdiction of Angstrom? Or is that an upstream an issue?
HAL/D-Bus integration for mobile devices Do some benchmarks and make a decision regarding to HAL (see above). Customize, implement or design and implement specific D-Bus interfaces needed for portable devices: - Network hotplugging - Card swapping - Screen rotation - Backlight control - Maybe phone interface communication - Maybe positioning device interface - Maybe camera interface - Special keys launching special actions - Headphones handling - Remote control - IrDA control - Idle, auto sleep, sleep blocking - Stylus Most of these proposals already exist from notebook world. Some of them needs to be created. Benefits of such design: - Reuse of existing design will allow to use conforming applications without porting - Applets don't need to poll to get status updates - Control can be done from command line or other applications without confusing of applets - No problem with permissions GPE GPE may be improved in many ways: - D-Busify GPE (see above). - Fix things broken by design (for example GPE applications menu issues system wake-up 10 times per second for no reason). - Fix usability with and without stylus. - Design new space saving widgets. - Fixes of GTK+ regarding of fixed spacing. - Fix unusable applications. - Fix failures.
As you've pointed out, it looks like like a lot of the things to make GPE usable fall under the d-bus option. I don't know that much about D-Bus, but I'm looking into it.
As a student, I'll probably be applying for these ideas, so I want to make sure I understand them.
I was not considering ideas on a deep enough level. The ideas I came up with were really just high-level issues that I've seen/heard about regarding Angstrom, I seemingly didn't put enough thought into what these ideas would entail. I like the D-Bus idea, but it seems like it's duplicating a lot of work(albeit on a system that may be broken), just using a different mechanism. Is that what we want to be spending time working on?
-- Jacob Thebault-Spieker Cell: (207) 717-5114
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
