Google Summer of Code

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:

1. Load each plugin in different threads
2. Add SVG support to theme manager
3. Better keyboard support for the canvas
4. Task Orientation plugin
5. Canvas Item based ScrollView Emulated
6. Porting to kde4 , plasma API
7. integrate KJS + XML so GUI can be made without coding

Needed Skills : Understanding of KDE3/4 architecture , And Qt3/4 programming skills.

Advace Keyboard support for CanvasView.

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),.

Task Orientation Plug-in for KBFX

What is TOM?

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)

What is a "Task Oriented Menu"?

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.

Todo list

Editor dialogs
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
Recent Documents
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
KDEDIR merging
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

Debate list

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

Basic requirements

• Config is stored in an XML
• This XML is saved by the config-sets name
• This/these XML is/are read and delivered to KBFX via Plugin
• The plugin should be able to merge multiple XML config setting files
• KBFX should be able to run multiple TOM plugins
  
• It should be possible to use further plugins right in the TOM Plugin -> The reasons are explained later

Store config as XML

• Easy to edit
• Can be extended in a simple way
• Structured
• Support for foreign charsets

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:

1. Father, uses Office-Functionality, uses Graphics and his digicam, the Internet and occasionnaly plays games
2. Mother, uses Office-Functionality, the Internet and occasionaly plays games
3. 17yrs old son, geek and student, uses Office-Functionality, graphics and his digicam, the Internet, plays games, develops, and administers the computer
   
4. 14yrs old son, student, uses Office-Functionality, Internet, plays games

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

XML Definition

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):

<TOM>
<TaskGroup: Browse>
<Name>
<locale:de>Durchst?bere...</locale>
<locale:en>Browse...</locale>
</Name>
<TaskAction: Internet>
<Name>
<locale:de>das Internet (WWW)</locale>
<locale:en>the Internet (WWW)</locale>
</Name>
<Program>/usr/bin/firefox.sh</Program>
<Name>Firefox</Name>
<Description>
<locale:de>Surfen Sie im Internet</locale>
<locale:en>Surf the Web</locale>
</TaskAction>


Contact...
Kontaktiere

ContactPlugin

</TaskGroup>
</TOM>

• The TaskGroup default attribute is the name used internally, not displayed
• The locale default attribute is the iso code of the language, and is taken to display the names and descriptions according to the country settings. If no locale tag for the language is found, the language tag without language attribute should be taken - if one exists - or the one with the en attribute. The element itself should probably be in ""
• The Program tag contains the command line to be executed upon launch
• Probably, a sort order mechanism should be implemented as well, either with an tag or by means of a rating with tags
• The XML should be UTF16 for foreign charset support
  

Things to be considered

• One Thing that should be considered is that - as long as the XML's are not delivered by the distributors, it can happen that Programs disappear. The logical solution would be to mark them with white X in a red circle, and if one clicks on it, he is given 3 choices:
  
• Search for the file that was linked
• Delete the entry
• Assign another Program to that task
• Personal Setting files should be stored in /home/user/kbfx, and we should provide an export function that copies that file to /usr/share/kbfx somewhere
• Loading should always have the two paths prepared as proposals for people to find it quickly
• Having a possibility to enter plugins somewhere in tom would be nice and feasible, I think. Example: Tasks write (tagged , organize (tag , Contact (tagged with the information to hook that in. That could - when a contact plugin exists, listing contacts and possibilities to contact them - then let you contact the matching contact directly.
• Instead of runtime-merging of multiple XML's, a personal XML could be created during the time you add another XML to the plugin. This - however - should have the origin marked to offer the possibility of sending these modifications back to the origin file.
• To have a real TOM, we should also include a Plugin (right hooked into tom) importing the todo list of the user's PIM. It would then
  
• launch the PIM, and display the task, if it has no attachments
• Open the attached file, if one file is attached
• Open a list with the attached files, if multiple files are attached
• This came to mind as I do actually work with the todo a lot...

Last Updated Monday, March 26 2007 @ 08:20 AM EEST|2,851 Hits