RE: [Pyatcron-devel-list] The previous changes plus some more

[Julien Olivier]

On Tue, 2004-04-13 at 10:01, NICOLOVICI Xavier wrote:
> Hi Julien
> 
> Thanks for your work, I will check it out on my private CVS tree and commit 
> changes today.
> 
> It's no problem for me to handle your patch, and commit them. Anyway, I have 
> no problem for you to commit changes directly on the main CVS tree. The only 
> thing is regarding the backend classes, I might rollback some of your 
> changes, depending on the ideas I had during the nights ;-)
> 

OK, thanks.

> Feel free to send me patch if you prefer.
> 

Yes, I prefer :)

> About the backend, and especially the SceduleList class. I've learned some 
> interesting things in Python this week, which makes possible thinking about 
> ScheduleList instance like Arrays. That way, we could retrieve a Scheduler 
> from a ScheduleList the same way youretrieve an element from an Array. I'm 
> working ot it actually.

> The above might obsolete the Sceduler.Id field. I have to think about it a 
> bit further.
> 

That's great news if it works. Using an Id can always be prone to
errors. Better get rid of it if possible.

> Give me a few hours from now to upload your code into the main CVS tree, and 
> some others to make my changes ;-)
> 

Take your time :)

> Another question I have in mind. Due to the fact that we want to implement a 
> kind of plugin system for new Task class, I assume that the Task Class itself 
> will have to draw it's GUI interface. How do you see this process works?
> I'm thinking about a method that will accept a Panel as parameter, and set 
> the GUI elements, signals and needed rollback functions. What do you think, 
> did you ever had a look at this?
> 

I haven't really thought of it, but my idea is that the plugin should
have a Gtk widget property. This widget would contain all the
preferences for this kind of task. Then, it should have a "validate"
method that would read the values of the sub-widgets (gtkentries,
gtkcheckboxes etc...) and set the task's values accordingly. I don't
think we need anything more. For example, I don't think we need signals,
but maybe I'm just missing something here. Another (more complicated)
method to handle that could be to simply define the GUI using an
XML-like format, and regenerate the GUI interface each time we need
it... The second solution has the advantage that it would be easier to
write plugins.

Now, I have a question: in the UI, there is a field called
"description". It's expected to show a human-readable description of the
task. How do you think we could keep those descriptions in the crontab
file ? My idea was to use comments in the crontab to handle them. For
example, for each task, use all the comments that come before it, and
after the precedent task, and set them as the description for this task.
Do you think it's possible for you to handle it in the parser class ?
What should we do if there are several lines of comments before a task ?
Cut them, and append "..." ?

PS: like I said in a former email, we haven't used the same coding style
in the different files we've coded so far. In the patch I've submitted,
I have tried to respect your coding style in the files you wrote, and
mine in the files I wrote. But I think we should "unify" our coding
style in a near future.

-- 
Julien Olivier <address@hidden>