On Sat, 2001-12-29 at 20:05, Nils Faerber wrote:
> > * Interopability. Say for example you are running a todo-application at
> > the same time you are running a calendar and you also get the list of
> > todo's in the calendar-application. If you then change anything in one
> > of them the other needs to be updated.
> This is one of the most difficult parts ;)
> And it's solved differently in all the systems I know of; most ignore it
> completely ;) Epoc32 for example uses a complex object oriented model for
> this where you include a object reference into foreign data (i.e. a
> contact object inside the schedule application).
> I think you are perfectly right to point out this problem and we will have
> to find a solution for it. But I do not think that IPC will help here a
> lot. Something like a object model or a set of libraries could do almost
> the same. If an application wants to import data from another application
> it could use a library of the other application to reuse it's code to
> get/store the data.
> Oh oh ... this becomes complex ;)
That's why I think it's important to solve it from the beginning.
> > > > * Over the ipc we need a run-this-program-only-once-system
> > > This can be very simply achieved using X11 features. Maybe you could
> > have
> > > a look at
> > > http://linux.companionlink.com/cpsutillib.htm
> > > and expecially the xsingleinstance utility
> > Ahh.. that sounds great also. As long as it's a library that the
> > applications can link to and not a separate program, I'm all for it.
> > The reason I don't want to use a separate program is because programs
> > will be started in many different ways (from menus, start-application,
> > other applications, commandline,....) and all will not remember to use
> > the xsingleinstance-command.
> It is a command, sorry ;)
> The problem you mention with it is IMHO only valid for other applications
> that want to start another application which is IMHO not necessary. The
> only application that starts others is the application manager application
> and mabye an extra menu application (which could also be the application
> manager just with a menu-tree view).
> Or do I miss something here?
Yes, hackers (in the "I like to hack"-sense, not the "I like to crack
systems"-sense :)
Lot's of people will create different launchers and menues and stuff.
Some will even like to use the commandline (there are strange people).
On the other hand the command to start the application can be a wrapper
.sh-script so that's no problem I think.
> > http://www.syncml.org/
> > basically all future (and some present) phones and handhelds from nokia,
> > ericsson, motorold, ibm, panasonic, symbian and others will use syncml.
> > If we use syncml it would mean that we can sync to any application that
> > supports those other devices. .. Well.. theoretically anyway.
> This is VERY important and your hint will for sure be very valuable!
> Me for exmaple did not yet know of this standard ;)
> Thanks!
You're welcome. I'm just trowing out ideas here and I think I've been
wrong in some (most?) of them :)
> > > > * Some way to be notified if a file is changed (using FAM for
> > example).
> > > > This would allow us to have the same cool active-sync as ms'
> > activesync.
> > > Also sounds interesting but I don't know it either. Link?
> >
> > http://oss.sgi.com/projects/fam/
> >
> > It would allow us to know exactly when a file has changed and with that
> > information we can easily do real time sync.
>
> Hmm ... maybe this can be handy. Do you think this is something we should
> consider right from the start or could we keep this as possible feature
> for the furture?
>
> The reason I ask is that I have the fear of getting too much needed
> fcuntionality into the project right from the start. If make it too
> complex before we even have a starting point we might end up like many
> projects: Good start but never reach even a first beta release...
I think this can be added later. Syncing application-data is another
issue that's alot more important.
> > > From my understanding of XML I see the following problems:
> > > - XML is completely ASCII based and thus there is a lot of redundancy
> > for
> > > the many repeating tags in the stored data.
> >
> > True, but I don't think that is a problem. There is no problem for qpe.
> Just because they use it does not make it any better ;)
If I thought that I wouldn't be discussing this :)
[Lot's of stuff about xml and sql cut]
I'm starting to agree with the sql (or at least database)-guys here.
> > Another thing I've been thinking about.
> > Regarding the window-manager. I totally agree that the windowmanger
> > should maximize the windows but we might not want to do that if they are
> > dialog-windows. Getting a Yes/No-question in a fullscreen-window seams
> > like overkill. Qpe and pocketpc both do dialogs as real windows (that
> > are always on top)
> The proposal that mallum <breakfast@10.am> posted recently takes care of
> this.
I just saw that after I sent the mail :)
/Erik - just joined the gpe-mailinglist.
-- Erik Bågfors | erik@bagfors.nu Supporter of free software | GSM +46 733 279 273 fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32Received on Sat Dec 29 11:39:42 2001
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:41:26 EDT