Open Source Sri Lanka has offered a mentorship in google summer of code. We as a project attached to it are part of this mentorship. First of all: what do we have to do with open source Sri Lanka? Well, as an opensource project, we are international. We have team members from different countries and continents. But our maintainer, the creator and main coder, is from Sri Lanka and has contacts to Open Source Sri Lanka. In fact, they support us quite a bit (let me take the occasion to thank them here). Now, where could people help? There are some things in progress and need completion. We could really need your help in following areas:
The Menu canvas items dose not support keyboard input's, this has to be added so that keyboard only navigation is possible. The key handling should be similar to that of a QListView, if the user selects on a group separator. then it should expend or fold the group (depending on the current state of the separator),.
TOM stands for Task Oriented Menu and is a work in progress that will become a
viable alternative to the current KMenu. Its goals include:
o Be task oriented
o Be simple and clear to use
o Create a smaller but usable menu
o Limited configurability through sensible defaults
o Have all configuration needs built right into the menu, including:
o Editor dialogs that can be called up from entries in the menu
o Context menus accessed by RMB clicking on a task for powerusers
o Allow locking down of menus through immutable settings
o Obeys Kicker and KDE Kiosk settings
o By making the TOM group of kickerrc immutable all config is removed
o By making a task group's rc file immutable, config options are removed
o Not require any modifications to the KDE menu system (applnk, etc)
A task oriented menu displays it's entries as "things to do" (or tasks) rather
than simply listing all items that are available. Each of these tasks has an
application or command associated with it, and this associated command can be
changed without changing the task name or placement within the menu. The tasks
are grouped by function and may map to programs, documents or actions.
Make the Destination entries work (only Run A Command is done)
Populate and track Recent Applications menu entries
o Application launching should be caught somewhere in the KDE libs, ala
Writing out of config files to reflect runtime changes (deleted entries, etc)
o This requires keeping track of the config files used in creating the menu
o KDEDIRS are already consulted for taskgroups, but groups of the same name
should be merged
Sane merging of menuext entries
o "Recent" items should go into the recent section
o Replace TOM's builin recent docs with the menuext version?
o Create a Recent Applications menuext?
o Add a way to quickly add/remove menuext items from TOM
(ala "Modify These Tasks")
Check for updates on launch and bring them down/install them if they exist
o this includes new apps installed on the local box showing up in the menu
o "Get cool stuff" integration?
Further refinement of wording / ordering in main menu (a perpetual TODO ;)
Creation of real-world task groups
Support plugins which can add arbitrary functionality to the menu
What should be the default task entry format be:
a) Task Name
b) Task Name (App Name)
c) App Name (Task Name) <-- silly option =)
Should "Run A Command..." be replaced by an inline combobox?
Pros: It's more obvious and will work even if kdesktop is gone. The widget
is already written (in tom.cc)
Cons: It makes it stand out too much over other entries, takes up more room
and isn't as powerful as the full minicli
---Part above is pasted from a Mail from Aaron Seigo
Design and Architecture
Store config as XML
Save by the config-set name
The idea is that one can easily transfer settings and import them to test without having to delete the carefully prepared own configuration.
This/these XML is/are read and delivered to KBFX via Plugin
The normal manner to make sure that changes and improvements can be delivered without actually touching the framework
The plugin should be able to merge multiple XML config setting files during runtime
Imagine a computer used by a group of persons. I explain by means of the following family:
They each have their own accounts. They each don't want to see the things they don't use. It would now be possible to have an XML for each of them. But 2 yrs later, the 17 yrs old leaves home, and the younger brother takes over system maintenance. Now he needs these progs. So the older one would have to set up the tom for system maintenance for his younger brother, who doesn't care of developping and gaming.
But if we provide possibility to hook in multiple XMLs per Plugin and merge them during runtime, they could have a baseXML with office and Internet functionality, a graphics XML for Graphics and Digicam, an XML for the games, an XML for developing and an XML for administration.
If a TaskGroup tag exists in multiple of those XMLs, it is only shown once, with the Tasks of all of those XML's. So the taskgroup could be "Write" and have the elements e.g. "a letter" from the office XML and "c++ code" from the developer XML. So redundant TaskGroups can be avoided and place can be saved.
Another scenario could be that a programmer writes a program set and -as enthusiast KBFX user- provides the TOM XML straight with it. No need to reconfigure KBFX TOM for the use with those programs, just hook in the new XML as well.
The Config editor should be able to merge multiple XML config setting fixed.
Now imagine that a user X is absolutely enthusiast of the program set of the above developer. But he has already created (for other programs) a task group name he likes better and also fits this developer's new program set. So he should be able to say "Import into XML", indicate in which Settings to import, from which file to import. He is then shown a list of all TaskGroups and Tasks of the XML with the import data, having checkboxes where he can select which parts (TaskGroups and/or Tasks) should be imported in the config editor, and subsequently, where in his original XML (for TaskGroups, which order, or as a subtaskgroup, for tasks into which task groups) he wants to import it to.
This makes the whole handling of new elements easier and gives developers the possibility to deliver the settings right with the programs.
KBFX should be able to run multiple TOM plugins
That's a personal preference that - however - seems important to me. If we take the family from above as an example again. The older son - being a geek - loved tweaking the pc and did a lot of administration. The younger - in this scenario - has taken over the task of system maintenance. He is savvy enough to do it, but being no geek, it's just once in a while he touches the administration. In the example above, the old son had all in the things in the same plugin instance. He used system maintenance often, so it was not disturbing to have that lot of entries in his tom. The younger however, is a different story. As he only seldom does administration, it slows down his access to the things he really needs (by simply existing there) without bringing him advantages. So he unloads the administration XML, adds a new instance of TOM at the bottom of the KBFX Plugins and hooks it in there. He can now use the Tom at the top for his regular work and just once in a while opens tom2 with the administration XML to do system maintenance. It's still around, accessible in KBFX, but not there, where he usually starts the tasks he uses day by day, so without making him scroll longer for his applications
I am no XML guru at all. I avoid the work to research a valid header definition. Instead I'll just concentrate on the content. The tags I use are (Please note that the text in red is the tags):
<locale:de>das Internet (WWW)</locale>
<locale:en>the Internet (WWW)</locale>
<locale:de>Surfen Sie im Internet</locale>
<locale:en>Surf the Web</locale>
Things to be considered