Google SoC: Improvements To KMenu

[Mike Dean]

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:

   - much more stable: uncaught exceptions in components would not
   propagate to the rest of the system
   - maintainable: it is much simpler to debug or enhance a small
   software component than it is a larger code base
   - extensible: write new component, connect it via IPC [D-Bus], viola,
   extended during runtime
   - UI scalability: think multi-head displays and even Synergy
   - 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).
   - language neutral: 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


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.


On 3/24/07, Kelly <lightsolphoenix at gmail.com> wrote:
>
> (I actually originally posted this to kde-devel, but I believe looking at
> the
> list purposes that this may be the more appropriate place)
>
> Oh, excuse me, I forgot that this would be my first post to this list.
>
> 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.
>
> Uh, sorry if this seems like begging, but I was hoping someone could give
> me
> some advice or potential fixes or something like that on my proposal for
> GSoC
> before the deadline, so I wouldn't end up stuck. It is located here:
>
>
> http://crystalsanctuary.rpgsource.net/dp_stuff/gsoc/proposals/KMenu_Layout.pdf
>
> Thanks in advance.
> --
> http://www.mozilla.org/products/firefox/ - Get Firefox!
> http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox!
>
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070326/221a8c37/attachment.htm>