[Kde-hardware-devel] Seeking for advices on kde solid dev, plugins dev.

Àlex Fiestas afiestas at kde.org
Sun Jul 13 23:01:36 UTC 2014


On Monday 07 July 2014 22:29:05 桥 杨 wrote:
> 
> Here is the exhaustive list:
> 
> 1.Use the idevicebackup tool for full and incremental native backups and
> restoring from them
> 
> 2.Use idevicesyslog tool to view the syslog in realtime.
> 
> 3.Use the idevicecrashreport tool to retrieve crash logs from a device.
> 
> 4. Use the ideviceprovision tool to manage provisioning profiles of a
> device.
> 
> 5.Use ideviceinstaller to list, install, uninstall and archive your own apps
> or to install carrier profiles.
> 
> 6.Use idevicerestore and libirecovery to update and restore devices.
> 
> 7.Use sbmanager to arrange icons on the device using drag and drop. iPad
> support is WIP.
> 
> Among these tools, ideviceinstaller, idevicerestore and sbmanager are tools
> based on libimobildevces. The others are tools along with libimobiledevice.
Have you checked if these tools have an stable api?
 
> In order to start implementation, I’ve got several basic questions:
> 
> 1. Is it acceptable that we use the cmd tools directly?  Or am I obliged to
> write an installer/ restorer using the apis of lib by myself ?  For I think
> it might not be	 worth rewriting an installer/restorer, theses apps do not
> have dev libs and I wouldn't be able to create a better or lighter for my
> uses in short time. But for such an application, I haven't got much
> experience on which would be healthier for an open source project.
It is acceptable as long as the cmd tools have a stable api, we don't want to 
have to switch how we use them every now and then.
> 2. What is a more properer way to call a cmd tool? I only know that QProcess
> can run cmd. Is it better to write a bash script to deal with the cmd and
> its out put or we deal with the output in qt program?
QProcess should be fine.

> 3.Is it better to integrate the panel into the panel of kdeconnect or maybe
> we create another one? current version of kdeconnect is mainly a tool
> connect our device with our workplace, cooperate, communicate with each
> other and control each other .  But this panel would be more likely to be
> an “iTunes for linux”. For me, maybe it’s better to build it as an
> independent program.
We can start with a separate tool and see how we merge them in the future, no?
> Besides, for the kdeconnect plugins I'm developping, I would also like to
> know :
> 
> 1.How to create/modify/delete alarm,event,calendar, note from korgnizer
> 
> 2.How to create/modify/delete contacts from kontact
These you should ask to kde-pim at kde.org.
 
Cheers!


More information about the Kde-hardware-devel mailing list