Re: Roadmap

Gonzalo Diethelm wrote:

>On Mon, 2005-04-04 at 16:32 +0200, Armin Bauer wrote:
>  
>
>>>Hum... "wid" == "when it's done"? Anyway, here I could probably try and
>>>help (GUIs are not my strong suit anyway); is there any documentation
>>>for how to write or port a plugin? Is there a "dummy" plugin that one
>>>can base a design on?
>>>
>>>      
>>>
>>sure!
>>there is an example plugin here:
>>http://www.opensync.org/browser/trunk/docs/example-plugin
>>
>>and you can also take a look at the doxygen documentation
>>http://www.opensync.org/docs/
>>
>>or some of the other plugins:
>>http://www.opensync.org/browser/plugins/
>>    
>>
>
>Ok, will look into that. My plan is to start thinking/working on the
>Evolution2 and/or the IrMC plugins; if anybody else is working on those,
>please let me know so I don't duplicate work.
>  
>
the evolution2 plugin in opensync is pretty much done. the only thing 
missing are the sync alerts (the evo2 plugin in 0.8X is a _lot_ older 
than the one in opensync).

the irmc plugin is not ported yet (and i think it would be a good idea 
to work over the plugin a bit while porting since the irmc plugin in 
0.8X is a bit unclean in some parts)

>  
>
>>>Ok, (my) emphasis on all plugins; what do you exactly mean with "fully
>>>working gui"? 
>>>
>>>      
>>>
>>i meant this:
>>"Another thing that should be done is to implement a new gui that takes 
>>advantage of the new
>>features of opensync (it can display the progress for example, allow 
>>syncgroups etc). I thought about implementing the new gui in qt4 so we 
>>can use the same gui for linux, windows and mac."
>>    
>>
>
>Ok. As usual, the choice of a toolkit (qt4, gtk+, etc.) will become a
>religious issue... One comment: if opensync is designed the way I am
>understanding, it could be a good idea to use an interpreted language
>for the gui (Tk, python, whatever); that would make it easily portable
>across OSs, windowing environments, etc.
>
>  
>
yes might be a good idea. i think the first binding is going to be the 
python binding so it might be a good idea to use this language.

and i dont think that the choice of a toolkit should get religious. i 
think the choice depends on what you want to accomplish. since i would 
like to target several platforms in the long run, using gtk might prove 
difficult (im a gtk user myself and would have to learn qt too).

>>i didnt publicize too strong yet since the usefulness of opensync is 
>>still very limited since the syncml plugin is missing. my idea was to 
>>"go public" once we have at least something to show.
>>
>>But maybe it really is a good idea to start with this now by just 
>>telling the people what the idea and the goal of opensync is and then do 
>>the same again once we reached the stage where the syncml plugin is working.
>>Maybe this would work: Start polishing the opensync.org website with the 
>>information about opensync so that it is immediately clear what opensync 
>>is and what it does (improve the wiki and the whitepaper etc), then try 
>>to get it onto some news sites.
>>
>>/me thinks we need someone with knowledge in marketing :)
>>    
>>
>
>I, of course, agree; "release early, release often" (as someone a lot
>more qualified than me once said) also applies to documentation and
>plans. Unluckily, I am no marketing buff...
>
>Best regards.
>
>  
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click