RE: [Pyatcron-devel-list] Task list in the main window

[Julien Olivier]

> Can someone explain to me what the plugins are, or give me a link?  I'm
> not sure I understand what you mean by this.
> 

Well, by plugins we mean that it should be possible to specify type of
tasks independently from the app.

For example, one should be able to create a type of tasks (like a
download task, or a backup task) as a python or C plugin. Then if you
install this plugin in a given directory (for example
/usr/share/pyatcron/plugins), pyatcron's assistant should be able to
propose this new task type.

Basically, a task plugin should provide a description of what it does, a
set to properties to set, and, for each property, a function to write
the cron config file to reflect the property.

For a more concrete example, the redhat-config-network tool uses plugins
to determine the type of connection you want to configure. For example,
xDSL and PPP are 2 plugins. Later, they could for example add "radio" or
"electrical cable" plugins for example... without modifying the main
tool.

> I was working on an assistant last night (see attached), that I didn't
> really get very far on, but I was able to get a layout of how it may
> look.  I copied the design of the redhat-config-packages main window.  I
> didn't go much farther because I'm still not sure how to create an
> assistant.  With several different widgets on it, I'm not sure if you
> just pile them all in boxes and make visible only the widgets on the
> current page, or if you can dynamically load each page from a separate
> glade file.  If I am making no sense whatsoever, it is because I really
> don't know how to go about an assistant.  :)  But I did like the design
> of the redhat-config-packages.
> 

I like your mockup very much. I think the assistant only needs a general
layout (which you created) and a free widget at the center. Then, we
would connect our widget (that would be generated by code, not using
glade) to the free widget in the assistant.

At least, that's the way I see it.

If anyone has a better idea...

> Again, I am still learning glade and gtk, so I if I am making major
> design no-no's please point them out, I am working on this project to
> learn.
> 

I only noticed two little problems:
 - you have to set the "visible" property to false because, else, the
assistant is displayed before you set it a transient of its parent. What
does that mean ? It simply means that, if the assistant is displayed
before the "self.win.set_transient_for (parent)" command, it will not be
centered on its parent (the main window).
 - you have to set the "modal" property true so that it is impossible to
click on the parent's window before closing the assistant.

> Also, for now since I am just learning I don't want to get in your way
> and cause you all more work, so I don't mind doing the coding if someone
> else wants to work on the layouts.

The whole objective of this project is to have fun, really. So I really
don't care if you break some little things. If you enjoy creating
layouts, I'm all for it ! Even if I have to modify them later.

The only thing is that, before mixing our work too much, we have to
decide clearly who does what. But it would be stupid to decide that I'll
do all the layouts simply because I know how to use glade. I mean, I
didn't know glade before using it a lot. And making mockups is a good
way to learn it.

>   I could probably do something simple
> like the about box, but I don't want to work on something for a while,
> then have to have someone else come along and clean up my mess.

Again, I don't see why you would create mess. And even if you did, it's
a good way to learn.

>   I also
> don't mind working on the nitty gritty coding, if there is certain
> features that need to be added, I will work on those.
> 

If you really don't want to work on layouts and want to start working on
the code, I think it would be good to define the tasks' basic class,
which might be called "PyAtCronTask". One good way to do it could be,
for example, to create the class and add the basic properties so that we
can implement a dynamic list of tasks. Each task would need an Id, a
name, an "active" boolean and a list of properties that should match
cron task options.

Then, you could modify the PyAtCronMainwin.updateTaskList method to use
the task class. More over, you could also implement the "deleteTask"
method.

> > Does anyone absolutely want to work on one precise dialog ? Or do you
> > want me to work on them ?
> 
> 
> You seem to be doing a good job, and are definitely quicker than I am at
> it.  ;-)  Unless Xavier has any objections, I'd say you're the man.
> 

Well, I'm quicker because I have some experience. But maybe you would
like to learn it too. So, I'll wait for your answer before going on. If
you finally decide to work on layouts, I'll work on the PyAtCronTask
class instead.

Let me also add that I don't have much work those days, that's why I'm
very active. But that could quickly change, sadly. So don't expect too
much from me :)

> > Do you have any artistic talent ? We might need a logo for the about
> > dialog.
> 
> As for the logo, I was using the
> /usr/share/icons/Bluecurve/48x48/apps/icon-datetime.png.  I think we
> could modify it a little to make it represent scheduled tasks rather
> than just a clock and a calendar.  Or did you have anything specific in
> mind.  If so let me know, and I can play around with it.
> 

I have strictly no idea :) I'm the worst artist you could have to work
with. So I'll let you 100% free to decide what is best.

> > 
> > Some notes: GNOME has both an about dialog and an assistant dialog
> > built-in. Sadly, they aren't available to GTK-only apps. That's why to
> > create them from scratch.
> 
> Unfortunately.  But all for the sake of portability.  ;-)
> 

Yes, I understand that.

> > 
> > PS: later we'll have to add an help dialog. But that's not a priority
> > for the moment, I think.
> 
> I could probably also work on that when the time comes.
> 

OK

-- 
Julien Olivier <address@hidden>