Re: [Bacula-devel] More Bacula GUI questions!

[Kern S. <ke...@si...>]

On Friday 02 December 2005 18:19, Lucas Di Pentima wrote:
> Kern Sibbald wrote, On 02/12/05 13:36:
> > Nice. I'm impressed.  I see you have a few more button icons too :-)
>
> Yes, I have added toggle-buttons to show/hide the console and stats
> pages :-)
>
> > An idea I had is to possibly make one higher level in the tree, where you
> > put perhaps 3 main categories:
> >
> > Catalog
> > Config
> > Functions
> >
> > Catalog, I think would contain what you currently have -- i.e. it is a
> > view of what exists in the Catalog.
> >
> > Config, would be a view of the config or resources.  It could be called
> > Resources too, which might be a better name.
>
> In what sense the resources differ from the "catalog objects"? I think
> they can be seen as the same thing...

There are certainly similarities, but they are quite different, and don't have 
all the same fields.  The Config objects are what you specify in the .conf 
file.  The Catalog objects are to a certain extent the result of part of the 
Config object, but in addition, they contain the history of what jobs have 
run.  In addition, you can change the Config -- for example some of the 
values in the Pool, and the Catalog pool will get updated when Bacula 
restarts.  However, any Volumes that were previously created will have 
different values.

>
> > Functions, could be various functions such as Label, Restore, Backup, ...
> > Or alternatively, and probably better, each Function could explictly be
> > listed in the tree, and possibly have subfunctions.  It might be a bit
> > weird to have functions in the browser section, but it seems to me that
> > it could be a convenient way to get to appropriate "dialog" tabs that you
> > could fill in to do things -- much like Nicolas does with the Restore tab
> > in wx-console.
>
> How about making this functions available via a special menu-bar or
> perhaps, more toolbar buttons? (or maybe both...). 

Yes, this is probably necessary in any case to make "short cuts" to certain 
high use functions.

> My idea of the tree 
> browser is that it should be a collection of the system's entities (aka:
> objects), not functions (methods). This functions may be added to the
> tree browser also as popup menu entries, so for example: a user expands
> the Clients subtree, and right-clicks on the "client1-fd" entry...there
> a popup menu appears with entries such as "restore full", "restore
> files...", etc...specifically to be applied to the selected object.

Perhaps you can do it the way you suggest, but the problem I am worried about 
is the fact that for certain functions such as restore, there are a *lot* of 
different variations.  Perhaps a simple dialog box with radio buttons and a 
few check boxes will allow organizing this ...  Anyway, my suggestion was 
just an idea.

>
> Also I think the tree as a browser will start to be uncomfortable if we
> add many levels to it, and if we change the semantics of its entries, it
> will be worse, what do you think?

I'm not too worried about a lot of levels, what is important is that the users 
understand what they are doing, and what objects they are viewing or 
operating on -- thus the need for a clear distinction between configuration 
data and catalog data.  Concerning the functions, I think we can go slowly, 
and start in the direction you suggest.  If we don't get where we want to be 
with that, I'll review my idea of putting the commands in the tree.   Haven't 
you ever wanted to see the whole list of commands?  Then click on one to see 
a list of all the various options?  That is my idea, whether it is in the 
browser tree or in a tab or a dialog box isn't the critical point.

-- 
Best regards,

Kern

  (">
  /\
  V_V