pyatcron-devel-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pyatcron-devel-list] My opinion


From: Julien Olivier
Subject: Re: [Pyatcron-devel-list] My opinion
Date: Thu, 15 Apr 2004 10:33:25 +0100

> * Julien, about the Scheduler.Id field, I would really like to get rid of it, 
> it's really something that might create problems (and the problems we have 
> now are good examples ;-)
> I've made the SchedulerList object act as a Python container. Then, it's easy 
> to get every elements, retrieve one by its index or event delete some.
> My vision for the GUI would be to reflect the content of a SchedulerList 
> container. That is, when a signal is emitted (open properties for Task, 
> delete Task,...), I would like the callback function receive either the Task 
> or its index number, and then deal with it to do what's needed.
> For example, the delete_task_event: when the delete task button is clicked, 
> the callback function should receive the index number of the highlighted 
> Task, perform a del() statement, and then refresh the GUI. No Scheduler Id's, 
> only index of a Python container. Is that not good ? ;-)
> What do you think?
> 

I think it could work. We get rid of the Id, and use the index in the
entry table.

> * I've started working on how make the *Task object build their own widgets 
> for their properties edition. I've commited some changes into CVS (again, see 
> CVS comments to learn more), and mainly added a file (lib/gui.py) that 
> contains a SchedulerEditor class. This class builds a dialog window that 
> let's the associated Task build it's own widgets. This has not been 
> integrated into the main GUI (Julien, what are you doing tonight :-)
> To test this SchedulerEditor, use the following code sample:
>         schedList = ScheduleList()
>         gui = SchedulerEditor(schedList[0])
>         gtk.main()
> Smart, isn't it?
> Ok, seriously, this approach gives full liberty to external developpers to 
> code some new specific Tasks without hacking the core GUI system of 
> address@hidden
> Again, what do you think?
> 

I've quickly tested it, and I have some observations.

First, I think that the Task::getEditorWidget method should only return
the widget, nothing more. The widget should be initialized
Task::__init__, and the widget.show() should be done by whoever wants to
display it.

My second observation is about the SchedulerEditor class. In this class,
you load a notebook containing 2 pages from a glade file. Then, you add
2 pages... This is not the right way to do it. The right way is to:
 - whether create an empty notebook in the glade file, and add the pages
through the code
 - or create a full notebook in the glade file, and not create the pages
in the code

I'll fix it, if you don't see what I mean.

Yesterday, I couldn't work on it for good reasons: watching football in
a pub ;)

But I'll try to work on it tonight.

BTW: Have you received my monster patch fixing the indentation issues,
and the nextRunTime bug ? I would appreciate it if you could commit it
before I start working on this.

> * I've send an email about some problems opening our Galde file. Simply 
> forget, I was *really* not using the right Glade version ;-)
> 

I've not received it...

> * And last but not least, address@hidden has now its own domain, 
> www.pyatcron.org. At the moment, It's a simple forward on Savannah system, 
> but anyway, it's now reserved.
> 

Great news ! Thanks. Who pays for it ? If there is a convenient way to
share the cost, I'm ready to participate.

-- 
Julien Olivier <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]