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

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

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


From: Childers, Matthew
Subject: RE: [Pyatcron-devel-list] Task list in the main window
Date: Tue, 11 Nov 2003 15:41:07 -0600

> > 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 see, gotcha!

> 
> > 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...

That sounds like a good plan.

> 
> > 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.

I was wondering why it wasn't centering on the parent.  I will make a
note of that.  Thanks.

> 
> > 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.

Your right there, I won't learn it if I don't use it, but I am
definitely not yet to the point of creating the interfaces that we will
be using.  I have learned a lot in the past couple days by taking your
mockups and playing with them, and looking over your code.  I like this,
because I get to see how it is done, and then I can play with adding
modifications.  Before we started yesterday I didn't know anything about
the TreeView widget and after trying to get the "grey-ed" out option
working, I am very well versed in it.  So this method of exploring it
after you get it working, works really well for me.
 
> 
> >   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.

True

> 
> >   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.

That works for me, I will try and start working on it this evening.  I
may have some questions, as I am new to OO programming as well.  :-)
Don't you just love newbie's.

> 
> > > 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.

Go ahead and work on the interfaces, and I will play with them once you
are done, and learn them.  I will go ahead and start the PyAtCronTask
class.

> 
> 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.
> 

If no one else is an artist (not that I am), I will do some work with
logo.


> > >
> > > 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>






reply via email to

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