[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 133131] New: migrate konsolekalendar functionality to dcop [or
From:       David Laban <alsuren () gmail ! com>
Date:       2006-08-28 13:16:22
Message-ID: 20060828151620.133131.alsuren () gmail ! com
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=133131         
           Summary: migrate konsolekalendar functionality to dcop [or dbus]
           Product: korganizer
           Version: 3.5
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: reinhold kainhofer com
        ReportedBy: alsuren gmail com


Version:           3.5 (using KDE 3.5.2, Gentoo)
Compiler:          Target: i686-pc-linux-gnu
OS:                Linux (i686) release 2.6.16-gentoo-r12

konsolekalendar is good enough for getting you out of trouble when KDE/X decides to \
screw you over the day before our exams, but not very nice for scripting with, \
especially when you have remote resources like google calendars. I would guess that \
more people know hot to use dcop than know about the existence of konsolekalendar.

The following functions would be *very* useful for viewing events in scripts (take a \
glance around in kdcop as inspiration. Kopete has some good ideas for addressing \
large numbers of contacts/metacontacts.):

QStringList resources() // returns unique identifiers

Qstring title(QString resource)
KURL locate(QString resource)
bool enabled(QString resource)
QStringList todaysEvents(QString resource) // unique identifiers

QString Summary(QString event)
ulong startTime(QString event) 
ulong endTime(QString event) // or any return type that pydcop or command line dcop \
can output for later casting QStringList categories(QString event)

Obviously, dcop should be implemented with the least possible effort on your part, as \
simple wrappers around your existing highest level functions. 

At present, I don't have any experience using konsolekalendar to edit calendars, so I \
can't say anything about which dcop hooks would be worth having.

As I say: these things would make it *much* easier to deal with remote resources. \
They would probably be easier to implement than making konsolekalendar tie in with \
the enabled/disabled remote/local resources, especially if it's meant to work even \
when everything else kills itself.


[prev in list] [next in list] [prev in thread] [next in thread]