On Wed, 05 Mar 2008 13:54:45 -0600 Jacob Thebault-Spieker wrote: > 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/ opkg > > > > These 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.
Me too. But this task needs low level insight. > 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? > Well, not. 99% of work needed on GPE is an upstream work. Ideas described in the previous mail were only straightforward extension of existing projects, and finding its problems. Nothing Angstrom specific. Nokia already uses HAL in their tablets. > 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. Only one part. There are many independent issues, which need high level programmer: - No integrated media player (gstreamer may be preferred, as it has an atomic design not integrating all codecs into one huge application). - No working music player (may be integrated with previous, but GUI must be different). - Improve usability of PIM. - No terminal (rxvt is not integrated and does not share clipboard, vte is only a dumb demo). Maemo has some apps, but I didn't checked them. > As a student, I'll probably be applying for these ideas, so I want to > make sure I understand them. Imagine tools like gnome-power-manager, gnome-volume-manager, NetworkManager. These tools are heavily based on HAL and provide hardware independent way to control suspend, idle suspend, battery charging, inserting and removal of cards etc. GPE needs lightweight counterpart of them. I guess that HAL/D-Bus is the right way for PDA devices, too. Here is a simpe example, how it works: udev/HAL broadcasts: "Hey, there is a new toy inserted into the SD slot. It is a memory card, here are details about this card..." User space tool checks it and answers: "Please mount it with these options..." Compare with script driven solution: udev identifies de ice and calls script; script does some checks and mounts the device. HAL has several benefits: - GUI has high level of control without need to be hardware specific - No SUID helpers, no problems with permissions - No expensive forks, execs or shell interpeters are needed - It's easy to write command line tools - It's easy to embed D-Bus interface to any application in any language. - It's easy to listen to signals and write advanced handlers as a simple addons (e. g.: Is it a card from my camera? If yes, import all photos.) There are also some downsides: - Easy to use NetworkManager way can handle by design only one network at once, all other are down (VPN is an exception and it is implemented there in a bit non-standard way). AFAIK NetworkManager still has some problems with dial-up. - ifup/ifdown can handle more networks. But it has not yet any D-Busified version. It handles hotplugging pretty well thanks to udev, but for example "No networking, went to offline", "Lost wireless AP" signals don't exist. ifup/ifdown is also a bit expensive - each signal causes running a batch of scripts. - There is not yet any design "fit for all" merging both. For example, while installing OpenSUSE, you have to choose one of the above. - And finally, even D-Bus has a downside. Its design has no simple support for situations, where you need ordered execution of different actions. Example: Got network connection and wants to flush mails. It's easy to do it using D-Bus. When network connection is established, signal is sent, mail handler gets it and flushes e-mails. Got network connection and wants to flush mails, but mail server is behind VPN. Must wait for VPN connection to be established. It's a problem. VPN handler does not know, that it shoud send signal "flush mails", mail handler does not know, that it should be triggered by "VPN established" and not "default route established" User may knows it, but defining the chain manually and telling network daemon to send signals differently makes the whole thing ugly. Designing an order-wise generic inter-application signalling could be a a separate SoC project. It will allow not only to fix above mentioned problem, but also could be a way to the future Linux booting process. It would need a SoC mentor from one of D-Bus or HAL developers or so. > 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? While implementing high level issues, you often consider, that lower level does not fit your needs. In this moment there are only two ways: - Add some code to the highest level to work around problems of lower level. This is an easy way, but it is not scalable and makes code more complicated. - Start thinking about backend rewrite using different ideas. Yes, each GUI environment duplicates a bit of the code. But this code is heavily dependent on the widget toolkit, should not be complicated and does not need any hardware specific hacks. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
