I think this is a rather difficult project for a Google SoC project.  I myself have had the idea of creating an abstraction framework for a kicker replacement. In order to fully realize the benefits of such a redesign, however, utilization of IPC mechanisms would be required.  By abstracting different aspects of the kicker panel and providing communications between the components via IPC, the Kicker panel would become:

<br><ul><li><span style="font-weight: bold;">much more stable: </span>uncaught exceptions in components would not propagate to the rest of the system</li><li><span style="font-weight: bold;">maintainable: </span>it is much simpler to debug or enhance a small software component than it is a larger code base

</li><li><span style="font-weight: bold;">extensible: </span>write new component, connect it via IPC [D-Bus], viola, extended during runtime<span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></li>

<li><span style="font-weight: bold;"><span style="font-weight: bold;">UI scalability: think multi-head displays and even Synergy</li><li><span style="font-weight: bold;">Resource scalability: having separate processes for each component would provide automatic scalability to allow utilization of multi-core processors, and when D-Bus has RPC implemented, could even allow scalability across machines on a network (should some novel component be developed for which this would actually be desirable).

<br></li><li><span style="font-weight: bold;">language neutral</span>: any language which is able to use the requisite IPC mechanism, D-Bus, and use any needed parts of the Qt and KDE libraries, would be usable to create a new component for the panel

</li></ul> To fully realize the gain in stability, a watchdog system would be required when components connected to the system do crash, so that they may be restarted.  The Kicker panel would be much less useful if one were unable to use the K menu because the component implementing it crashed and didn't come back up.

In order to realize the benefits of greater maintainability, the code must be well written and clearly documented. In order to realize the benefits of extensibility, a solid, easy to use extension API would need to be created for each intended language with which components are to be created.

In order to realize the benefits of UI scalability, sophisticated communications and synchronization primitives may need to be utilized throughout the design.  This issue can be mitigated, however, by creating a good design wherein each component is rather simple and standalone, much like the shell utilities in GNU are simple and standalone.  Being simple and standalone does not prevent them from being sophisticated.

In order to realize the benefits of Resource Scalability, no extra work would be required, as asynchronous communications is the most natural fit for this type of design whether or not resource scalability is considered in the design.  Basically, no matter how you slice the pie, synchronization primitives would be essential in such a design.

In order to realize the benefits of language neutrality for the components, see the extensibility requirements above, as the requirements for extensibility are interrelated with the requirements for language neutrality.

In summary, while I think this is the direction KDE should go with Kicker, it seems like a bit much for a Google SoC project to tackle.  This is a project which could easily benefit from the creation of sub-projects to accomplish the various goals of the design.  This would be a true framework, and is therefore a larger project unto itself.  Perhaps, though, enough people may be interested in working on such a project that it might still be a viable goal to make some portion of the work your SoC project.  Without providing the appropriate abstraction via IPC, there would be far fewer gains for the effort, and in fact would require considerably more work, as it would lead to a much larger, more complex interlocking framework, rather than a more loosely coupled overall framework composed of smaller and more manageable sub-frameworks.

<br><br><br><div><span class="gmail_quote">On 3/24/07, <b class="gmail_sendername">Kelly</b> <<a href="mailto:lightsolphoenix@gmail.com">lightsolphoenix@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

(I actually originally posted this to kde-devel, but I believe looking at the<br>list purposes that this may be the more appropriate place)<br><br>Oh, excuse me, I forgot that this would be my first post to this list.<br>

My name is Kelly Miller, and I'm a college student (well, considering the topic, that's rather obvious...). KDE is and remains my favourite desktop on Linux, and I wanted to try and help out in some way.

<br><br>Uh, sorry if this seems like begging, but I was hoping someone could give me<br>some advice or potential fixes or something like that on my proposal for GSoC<br>before the deadline, so I wouldn't end up stuck. It is located here:

<br><br><a href="http://crystalsanctuary.rpgsource.net/dp_stuff/gsoc/proposals/KMenu_Layout.pdf">http://crystalsanctuary.rpgsource.net/dp_stuff/gsoc/proposals/KMenu_Layout.pdf</a><br><br>Thanks in advance.<br>--<br><a href="http://www.mozilla.org/products/firefox/">

http://www.mozilla.org/products/firefox/</a> - Get Firefox! <a href="http://www.mozilla.org/products/thunderbird/">http://www.mozilla.org/products/thunderbird/</a> - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments.

<br>See <a href="http://www.gnu.org/philosophy/no-word-attachments.html">http://www.gnu.org/philosophy/no-word-attachments.html</a><br></blockquote></div><br>