[Top][All Lists]

[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?
> > 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,
> 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
> to determine the type of connection you want to configure. For
> xDSL and PPP are 2 plugins. Later, they could for example add "radio"
> "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
> > 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
> > 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
> > glade file.  If I am making no sense whatsoever, it is because I
> > don't know how to go about an assistant.  :)  But I did like the
> > of the redhat-config-packages.
> >
> I like your mockup very much. I think the assistant only needs a
> 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
> > 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.
> does that mean ? It simply means that, if the assistant is displayed
> before the " (parent)" command, it will not
> centered on its parent (the main window).
>  - you have to set the "modal" property true so that it is impossible
> 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
> > and cause you all more work, so I don't mind doing the coding if
> > else wants to work on the layouts.
> The whole objective of this project is to have fun, really. So I
> 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
> 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
> > 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,
> 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
> 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
> 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
> 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
> > > 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.
> 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

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

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