Talk:Projects/Summer of Code/2009/Ideas - Revision history

Zander: /* Work on GTK+ integration */

2009-03-18T13:34:09Z

‎Work on GTK+ integration

Tampakrap at 13:23, 18 March 2009

2009-03-18T13:23:31Z

Zander: /* Work on GTK+ integration */

2009-03-18T13:11:25Z

‎Work on GTK+ integration

Tampakrap: /* Work on GTK+ integration */ new section

2009-03-18T12:24:46Z

‎Work on GTK+ integration: new section

Krake: Added comment to first talk entry

2009-02-25T20:57:36Z

Added comment to first talk entry

Tampakrap at 20:47, 25 February 2009

2009-02-25T20:47:46Z

Tampakrap: GCal in akonadi?

2009-02-12T00:12:05Z

GCal in akonadi?

New page

=== Google calender support for Akonadi/KOrganizer ===
I don't have sufficient knowledge of the codebase to write up a full blown proposal, but since GSoC is sponsored by google and for KDE, wouldn't this be a perfect project for it? I seen where akondi devs have talked about GCal support, but I haven't seen anything come of it. Full co-operation between kontact and Google apps would be a dream come true -- When I'm forced to use a non-linux box, I could just open up google and everything I need would be there -- from email to calendars to rss feeds. If only GCal supported "Todo"'s.... I suppose the only problem here is if this project would be doable in the constraints of GSoC.

@@ Line 9: / Line 9: @@
 Shouldn't this SoC be based on porting the composer to be based off of WebKit/KHTML with contentEdtiable? It is the only way KMail is ever going to properly support rich email creation.  The current composer is about 5 years behind the times in capabilities because it is based off of QRichTextEdit.
-== Work on GTK+ integration ==
+== Work on GTK+ application integration into KDE ==
 Yes I know those are not part of official KDE4 but IMHO those are needed and many people use them. It would be very benefical to KDE to improve things in those projects and maybe even support them officially. And without KDE support those have no chance to be part of GSoC2009. If anyone says it should be done on GNOME/GTK+ front  I do agree but sadly I don't think they care enough about KDE to do so.
 http://www.kde-apps.org/content/show.php?content=36077
 http://gtk-qt.ecs.soton.ac.uk/
-In general it is about improving how GTK+ apps integrate when running in KDE4 desktop.
+In general it is about improving how GTK+ apps integrate when running in KDE4 desktop, so be aware that KDE might not have any mentors for this.

← Older revision		Revision as of 13:23, 18 March 2009
Line 15:		Line 15:

	Just for consideration. <Ehm; these projects are part of Qt and quite complete already; whats the SoC project here? (TZndr)>		Just for consideration. <Ehm; these projects are part of Qt and quite complete already; whats the SoC project here? (TZndr)>
		+	<{Val}I'm not talking about improving QGTKStyle but the KDE counterparts : Kgtk and GTKQtengines :
		+	http://www.kde-apps.org/content/show.php?content=36077
		+	http://gtk-qt.ecs.soton.ac.uk/
		+	In general it is about improving how GTK+ apps integrate when running in KDE4 desktop.

← Older revision		Revision as of 13:11, 18 March 2009
Line 14:		Line 14:
	Yes I know those are not part of official KDE4 but IMHO those are needed and many people use them. It would be very benefical to KDE to improve things in those projects and maybe even support them officially. And without KDE support those have no chance to be part of GSoC2009. If anyone says it should be done on GNOME/GTK+ front I do agree but sadly I don't think they care enough about KDE to do so.		Yes I know those are not part of official KDE4 but IMHO those are needed and many people use them. It would be very benefical to KDE to improve things in those projects and maybe even support them officially. And without KDE support those have no chance to be part of GSoC2009. If anyone says it should be done on GNOME/GTK+ front I do agree but sadly I don't think they care enough about KDE to do so.

−	Just for consideration.	+	Just for consideration. <Ehm; these projects are part of Qt and quite complete already; whats the SoC project here? (TZndr)>

← Older revision		Revision as of 12:24, 18 March 2009
Line 8:		Line 8:

	Shouldn't this SoC be based on porting the composer to be based off of WebKit/KHTML with contentEdtiable? It is the only way KMail is ever going to properly support rich email creation. The current composer is about 5 years behind the times in capabilities because it is based off of QRichTextEdit.		Shouldn't this SoC be based on porting the composer to be based off of WebKit/KHTML with contentEdtiable? It is the only way KMail is ever going to properly support rich email creation. The current composer is about 5 years behind the times in capabilities because it is based off of QRichTextEdit.
		+
		+	== Work on GTK+ integration ==
		+
		+	GNOME since Qt4.5 has a nice integration for Qt4 apps with QGTKStyle. This is done for: theming, file dialogs ,Open/Save file, OK/Cancel vs the gnome way Cancel/OK buttons. Similiar projects exist for KDE4: GTKQtEngines, Kgtk.
		+	Yes I know those are not part of official KDE4 but IMHO those are needed and many people use them. It would be very benefical to KDE to improve things in those projects and maybe even support them officially. And without KDE support those have no chance to be part of GSoC2009. If anyone says it should be done on GNOME/GTK+ front I do agree but sadly I don't think they care enough about KDE to do so.
		+
		+	Just for consideration.

@@ Line 1: / Line 1: @@
 === Google calender support for Akonadi/KOrganizer ===
 I don't have sufficient knowledge of the codebase to write up a full blown proposal, but since GSoC is sponsored by google and for KDE, wouldn't this be a perfect project for it? I seen where akondi devs have talked about GCal support, but I haven't seen anything come of it. Full co-operation between kontact and Google apps would be a dream come true -- When I'm forced to use a non-linux box, I could just open up google and everything I need would be there -- from email to calendars to rss feeds. If only GCal supported "Todo"'s.... I suppose the only problem here is if this project would be doable in the constraints of GSoC.
 === KMail HTML support ===
 Shouldn't this SoC be based on porting the composer to be based off of WebKit/KHTML with contentEdtiable? It is the only way KMail is ever going to properly support rich email creation.  The current composer is about 5 years behind the times in capabilities because it is based off of QRichTextEdit.

← Older revision		Revision as of 20:47, 25 February 2009
Line 1:		Line 1:
	=== Google calender support for Akonadi/KOrganizer ===		=== Google calender support for Akonadi/KOrganizer ===
	I don't have sufficient knowledge of the codebase to write up a full blown proposal, but since GSoC is sponsored by google and for KDE, wouldn't this be a perfect project for it? I seen where akondi devs have talked about GCal support, but I haven't seen anything come of it. Full co-operation between kontact and Google apps would be a dream come true -- When I'm forced to use a non-linux box, I could just open up google and everything I need would be there -- from email to calendars to rss feeds. If only GCal supported "Todo"'s.... I suppose the only problem here is if this project would be doable in the constraints of GSoC.		I don't have sufficient knowledge of the codebase to write up a full blown proposal, but since GSoC is sponsored by google and for KDE, wouldn't this be a perfect project for it? I seen where akondi devs have talked about GCal support, but I haven't seen anything come of it. Full co-operation between kontact and Google apps would be a dream come true -- When I'm forced to use a non-linux box, I could just open up google and everything I need would be there -- from email to calendars to rss feeds. If only GCal supported "Todo"'s.... I suppose the only problem here is if this project would be doable in the constraints of GSoC.
		+
		+	=== KMail HTML support ===
		+
		+	Shouldn't this SoC be based on porting the composer to be based off of WebKit/KHTML with contentEdtiable? It is the only way KMail is ever going to properly support rich email creation. The current composer is about 5 years behind the times in capabilities because it is based off of QRichTextEdit.