View source for Talk:Projects/Summer of Code/2007/Ideas

Welcome to Summer of Code 2007 discussion page.

== KPDF projects of last year ==
Hi,
what about the KPDF-projects of the last year? Are they still valid and will there be some in this year? I am realy interessted in. -- Morton

:Projects from last year are probably still valid, but you can email any contacts listed to be sure. [[User:Thiago|thiago]] 08:05, 5 March 2007 (CET)
::Most of them are still valid. I'll put down some ideas for okular next days. [[User:Pino|Pino]] 19:35, 5 March 2007 (CET)

== Removed distinction between sponsored and non-sponsored ==

I have edited the page to remove the distinction between sponsored and non-sponsored ideas. The final decision rests with the student anyways, so there's no point in keeping the ideas with mentor as "first-class".

All ideas are good.
[[User:Thiago|thiago]] 21:15, 5 March 2007 (CET)

== Project "Whatsthis" ==

I don't know what category "Whatsthis" falls on. It looks Usability to me, but if I'm wrong, can someone please fix this?
[[User:Thiago|thiago]] 21:16, 5 March 2007 (CET)

== Scanning ==

libkscan and kooka are effectively abandoned code.  libkscan needs a complete re-write to enable the full feature set of SANE, to work with Solid, and to improve usability.  Kooka needs to be replaced with a basic quick scan utility and a more advanced app similar to XSane.


== Inline Spell-checking in Kateparts ==

I don't know if with the new sonnet framework wold be possible to do inline spell-checking in programs that use katepart (like kile) but if this is not possible it wold be a WONDERFULL idea. There are a LOT of people who use kile as a front-end to latex, and the only option that missed it's an inline spell-checker.

:Write a proposal for that idea in the main page. Maybe someone can implement it. In any case, make sure the Sonnet lead developer knows of it. [[User:Thiago|thiago]] 13:33, 7 March 2007 (CET)

== Entry removed: Konqueror - web browser ==

I removed the following text from the main page because it's not a proposal. It's just a description of user experience:

::I have use Konqueror for several years now. I like it and use it as 1st choice but at some point I have to start using a different browser. This is often down to java script on web pages not being compatible any more. It seems that many sites are happy with their pages providing it works with ms explorer. I wonder if this problem could be cured by using Sun's java issues rather than the one that is currently used and of course making updates easy. Unfortunately I find Opera to be the most useful alternative. It's mostly kept upto date.

::There are a bewildering variety windoze browser pluggins about and linux is often left out in the cold. Opera seem to have a partial answer to this in that the provide a pluggin for other pluggins. They leave the authoring of the latter to others. Is it possible to create a Konqueror pluggin that can make use of ms explorer pluggins? To be really useful it would need to provide the correct credentials and download and install the pluggin as well. Opera seems to rely on people keeping repositories of the required software. That isn't ideal but could be workable.

::One last thought. I used Midnight Commander to extract a single file from an rpm the other day. Something that doesn't crop up very often but is a useful facility. Currently the only option I have under Konqueror is to install it with Suse's Yast. I wouldn't like to loose that.

I also made an entry for the last point as an idea (Ability to extract files from RPM files). If someone wants to take up the user experience above and turn into a project proposal, go ahead.

[[User:Thiago|thiago]] 17:49, 15 March 2007 (CET)

== korganizer, google calendar and kpilot? ==

As I'm not sure if there's already an easy way to keep Palm's organizer/calendar synchronized with Korganizer and Google Calendar, I'm first asking here, before adding it as an idea.

For the korganizer-kpilot part seems to already exist. But AFAIK there's currently no way of keeping Google Calendar calendars synchronised (that means: keeping update korganizer's calendar by checking frequently for changes on google calendar, same as updating the google calendar when changes are made to local calendar, etc) with Korganizer's calendars. What do you people think? - Raphael


== NOTE: About the KDevelop/Snippet proposal ==

This is referring to the [http://techbase.kde.org/Projects/Summer_of_Code/2007/Ideas#Extend_KDevelop.27s_snippet_support "snippet"-related proposal].

I would recommend NOT to pursue ANY efforts related to this proposal without talking FIRST to 
the maintainer of the original snippet kpart, who has in fact repeatedly mentioned an interest 
in implementing several of the key features mentioned in the feature request (and SoC proposal)
for kdevelop 4.0:

* http://lists.kde.org/?l=kdevelop-devel&m=115443930400711&w=2
* http://lists.kde.org/?l=kdevelop-devel&m=114870551104936&w=2
* http://lists.kde.org/?l=kdevelop-devel&m=117460024629536&w=2
Also, if you do check out the plugins/snippet directory from SVN, you'll notice that there
was just recently relevant modifications committed to the repository:

http://lxr.kde.org/source/KDE/kdevelop/plugins/snippet/

While this SoC proposal and the mailing list discussions have obviously some differing visions, 
there are too many commonalities. So, for the sake of the snippets kpart itself, it would
probably be best to start coordinating all related efforts (there were for example some
interesting suggestions related to enabling users to literally "share" code snippets and
repositories via network, likewise the currently pursued implementation (in SVN/HEAD) approach 
WRT snippet "databases" (or "repositories"), seems much more intuitive, mature and reliable 
than really coming up with a custom XML file format for all conceivable scenarios, providing
a snippet-specific customization (shell) script, which may be implemented using arbitrary
languages (such as for example, awk, sed, perl, python), also seems much more powerful and
extensible. OTOH, providing standalone exports of snippet databases ("repositories") would
still seem like a good idea, which of course could still be accomplished using the current
approach, by simply compressing each directory structure in some compressed format (zip,
tgz, bz2), which may possibly be even accessed directly, in a transparent fashion).