Re: [Bacula-devel] bat design issues

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

On Monday 19 March 2007 16:32, Dirk Bartley wrote:
> Greetings
>=20
> My name is Dirk Bartley and I've started working with Kern on bat.  I
> hope to be helpful.
>=20
> I'm learning qt.  Kern committed a patch of mine into head of a decent
> start at an interface that is a tree of media.  It has a root object and
> each pool would be a branch, then each media object would be a branch of
> the pool.  This is in head.
>=20
> This weekend I started in a working branch so that I could commit
> changes for Kern to comment on before committing to head.  If your
> familiar with svn just change your pwd to bacula/src and issue the
> command "svn switch svn switch
>=20
https://bacula.svn.sourceforge.net/svnroot/bacula/branches/working/qt-conso=
le=20
qt-console qt-console" and you can see that.

Thanks for introducing yourself :-)

>=20
> We are running into some issues as you can see and looking for comments
> and assistance.  Now on with the reply.
>=20
> Number 2
> Ok, there is alot here.  There are some interface decisions to be made.
> Not being extremely familiar with qt widgets, Im not sure how to best be
> of assistance.=20

I'm in exactly the same boat, not too much in front of you.

> I was hoping to plow through adding a few interfaces=20
> before trying to tackle something like this, but you cross bridges when
> they come.

That has been and will continue to be my attitude.  As long as we construct=
=20
most or all our GUI interface with designer, whether they end up in a stack=
ed=20
widget, a separate window, a docked widget, it won't really matter or chang=
e=20
either our interface or our code -- it might have a small impact on how we=
=20
startup pages/windows.

>=20
> As a user I've worked with lots of interfaces and MDI has never been an
> issue to me.  I do see the advantages of being able to pull a child
> window out of a main window so that you can enter information in one
> while looking at another.  I have no problem starting over with a
> different interface and look.  I'm still early into this.

I'm still early into this too, I'm just trying to move forward with more pa=
ges=20
such as what you are working on, and at the same time, slowly working on=20
getting at least one example of every thing we need working. =20

>=20
> Gui iterfaces that I have liked most have been tabbed.  This shows the
> existing windows available to the user.  The disadvantage I see with
> that is identifying a window as being connected to which of a potential
> multiple directors.

Yes, within a page (stacked widget), you can put a tabbed interface.  If yo=
u=20
have enough tabs for your interface, do not hesitate to use it.  I don't=20
think a tabbed interface will work in place of our page selector because I=
=20
expect to have something like 20-50 page selections under each Director and=
=20
multiple Directors in the page selector.

>=20
> On Mon, 2007-03-19 at 11:46 +0100, Kern Sibbald wrote:
>=20
> > 2. User Interface issues (docked widgets, dialogs, ...)
> > One of the fundamental features I want to have in bat is the ability to=
=20
> > display multiple things at the same time.  By that I mean, while one is=
 in=20
a=20
> > restore session, you might be asked to enter JobIds or MediaIds. =20
Hopefully=20
> > the interface will present you with a list of these, but in some cases,=
 I=20
can=20
> > imagine that one will want other information from a different page with=
in=20
> > bat. That implies being able to see two windows at the same time.  It a=
lso=20
> > implies multiplexing the bat<->Dir connection (see next item for=20
multiplexing=20
> > issues).  At the current time, we have neither of these.
> I never thought of the multiplexing issues.  Guess that's why your the
> project leader.=20
> > =20
> >=20
> > First, I don't like MDI.  It has certain features we need but I find th=
at=20
> > having the windows restricted to the main window is very limiting. =20
Perhaps I=20
> > should look at the Qt MDI because it could permit allowing floating=20
windows.
> > What I did try to implement was docked windows, because on the surface =
it=20
will=20
> > give us what we want -- windows that are attached to the bat page windo=
w=20
area=20
> > but that can be undocked and can float.  The problem is that for severa=
l=20
> > reasons, it just doesn't work.  As far as I can see, it relies on havin=
g a=20
> > CentralWidget and the docked windows fit in around the central widget. =
 In=20
> > the code I wrote to have docked windows, designer chose the central win=
dow=20
to=20
> > be the main bat window.  In any case, we do not have a single central=20
window. =20
> > In Qt, when a docked window is docked, it is next to the central window=
,=20
and=20
> > they automatically add a splitter.  In our current design, I don't see =
how=20
> > that can work.
> >=20
> > I haven't had time to explore it, but I suspect that we can get what we=
=20
want=20
> > by having paged windows as currently exist, then providing a button tha=
t=20
> > allows you to detach the page into a separate window -- to be explored.
>=20
> That may be a good method.  It's the how to get it to work part.=20
>=20
> > By the way, for the moment, I prefer to instantiate all the different=20
pages at=20
> > startup time.  This gives a bit of a pause in the beginning, but then=20
> > clicking through different pages is very rapid.  Long term, when we hav=
e=20
lots=20
> > of pageswe will need to provide a means to instantiate the most common=
=20
pages=20
> > at the beginning and others later.  We can even load pages dynamically=
=20
(i.e.=20
> > create the user interface dynamically), and this is something to consid=
er=20
for=20
> > making plugins ...
>=20
> Just concerned about which ones windows to open at start.=20

I wasn't really specific enough here.  It isn't a question of "opening"=20
windows in the sense of populating them with data.  That can be done when t=
he=20
page is selected either by single clicking the page selector or double=20
clicking it.  What I really meant was instantiating the pages, which means=
=20
creating all the widgets.  For example the brestore page is instantiated, b=
ut=20
it is not populated with data.

The question of exactly when to populate a page is important, because when =
you=20
single click on a page selector, you don't normally want the page to be=20
populated.  It is pulled forward on the top of the stack, but if you=20
re-populate it each time it is pulled forward, you will lose whatever you=20
were previously working on.  Either we need to stick to what you did, which=
=20
was to populate your widget on a double click of the page selector, or have=
 a=20
special button either on the button bar or on the page itself that will do =
a=20
refresh.

> A list of=20
> jobs for some sites might be quite long and take a while to get all of
> the objects from the director.  Just want to accomodate a quick start of
> the application for a reasonable worst case scenario.  Say a bat client
> connecting to a slow server over a not so optimal wan.  That sounds like
> my site.

Yes, this is the difference between instantiating (i.e. creating the widget=
s)=20
and populating the page or window (i.e. getting the data from the Director)=
=20
that I was talking about above.  The two concepts need to be differentiated=
=20
but very obvious and intuitive to the user.

>=20
> I also am hoping to have many windows created on the fly that are querry
> specific.  Jobs on a specific media, media a single job spans over, jobs
> a certain file is in, media a certain file is in.  I think this list can
> grow large over time.

This sounds fine.

>=20
> If amongst the list, we cannot figure out what would be the very good
> interface, maybe going straight to someone for help would be possible.

I think Jos=E9 may be of some help in this regard with the User Interface p=
erson=20
he is going to put part-time on this project.

> Maybe evan if someone approched Trolltech???  Hopefully, we have a
> resident with the qt knowledge.  Nudge Nudge, Hint Hint.

I've looked at the Trolltech site, and am a bit discouraged because all I s=
ee=20
is a commercial company. I see no place where an open source developer can=
=20
sign up for an email list or receive support.  This may be because I was to=
o=20
rushed to carefully look.=20

I have signed up for a Trolltech Internet 2 hour course on converting from =
Qt3=20
to Qt4.  Perhaps that will provide us with a bit of information.  It is als=
o=20
possible we could get some help from the KDE project.  However, I would lik=
e=20
to keep bat pure Qt so that it will be more portable.  If we start adding K=
DE=20
widgets,... the portability will be lost.

>=20
> > 3. Bacula API
> > The API with the Director is progressing. =20
> >=20
> > One thing I am considering is creating a mechanism whereby we can cance=
l a=20
> > command that runs too long (e.g. an SQL command ...)  Unfortunately thi=
s=20
is=20
> > not so simple, because there is no simple way to abort an SQL command, =
nor=20
is=20
> > there any simple way to abort any console command in Bacula.
>=20
> My 0.02, how about a dialog that pops up when a command occurs, or
> having the mouse change.

The problem is how to inform the Director to cancel the command.  While=20
running the command, the Director is not listening to the comm port.  Even =
if=20
I make it listen, you cannot just simply interrupt a running thread.  I hav=
e=20
some ideas, but it is not a given.  In any case, this is something far beyo=
nd=20
what we have today, so I'm not particularly worried about it, other than to=
=20
mention it as an issue.

>=20
> >=20
> > 4. SQL issues
> > There are two main things that we need from SQL: 1. the attributes of a=
=20
> > particular table, or the attributes of a query (i.e. how many lines wer=
e=20
> > deleted, ...).  2. Get back data in response to a query.
> >=20
> > For the moment, because bat knows the data structures,
> ?? How does bat know the data structures??

Bat (or you) knows exactly what columns exist in a Media record for example=
=2E =20
Most SQL interfaces provide for discovery of what tables exist, what the=20
columns are, and what all the column types are.  In principle, bat (you, th=
e=20
programmer) already knows all that. =20

>=20
> >  I am going to ignore=20
> > item 1 and simply say that we can implement it later if needed.  What i=
s=20
> > important is item 2, and I think the solution is really simple.  We nee=
d=20
two=20
> > things.  1. a command that defines the field separator for the columns=
=20
that=20
> > are returned.  2. a command that sends an SQL command and returns the=20
data.
> > Item 1 is simply a new Bacula dot command (I suggest we standardize on =
the=20
tab=20
> > character as a default field separator), but it should be settable via =
a=20
> > command.  Item 2 is much like the Bacula API issue discussed above.  I=
=20
think=20
> > what you need is a new command such as ".query SQL command" that you ca=
n=20
send=20
> > to the Director, and it in turn returns a list of all the data, and=20
possibly=20
> > an error indicator/message.  This should handle 95% of everything we ne=
ed.=20
> > The other 5% will be specific new Director dot commands.
>=20
> Sounds good to me.  This is probably the most important issue in moving
> forward with creating windows.  I can have everything come up as a new
> window for now and move the code into whatever widget or class we decide
> on at some point in the future.

That is sort of what I have been doing, except I put my windows on the butt=
on=20
bar, and I need to back integrate them into the page selector since we will=
=20
quickly run out of buttons.  In any case, certain of the most common action=
s=20
should have buttons, and all the actions or commands need to be added to a=
=20
Command Menu item as well as being accessible through the page selector.

>=20
> >=20
> > 5. Orphanned buffer problems (memory leaks)
> Vroom,  over my head for the moment.

OK, don't worry too much about it.  However, think about adding destructors=
=20
for any of the windows you create if those windows will be destroyed and if=
=20
they have allocated memory in the class.  Any of the widgets that form the=
=20
window will automatically be destroyed when the window is destroyed, but if=
=20
you do a "new xxx" and store the pointer in the class, that pointer will no=
t=20
be automatically released.   For the moment, I haven't worried about this a=
t=20
all, so you won't find any good examples in my code :-)

>=20
> >=20
> > 6. Unicode issues
> > Bacula works in UTF-8 and Qt works in Unicode.  A the current time, I d=
o=20
no=20
> > translation, but simply tell Qt that the information from Bacula is "ch=
ar=20
*"=20
> > so I imagine it is assuming that it is ASCII data.  This must be correc=
ted=20
> > and relatively quickly so that we are sure that Qt is doing a proper=20
> > translation from UTF-8 for all the Bacula supplied data.  In going from=
 Qt=20
to=20
> > Bacula, I generally use their toUtf8() function, so that anything enter=
ed=20
in=20
> > bat will be properly converted to UTF-8.
> Would it be easiest to keep the console class between all other parts of
> bat and the director??  I think that's what your saying here.

Yes, that is part of what I am saying.  The console class will do all the=20
conversion automatically.  However, for the moment, the data from the=20
Director is not properly converted into Unicode.  I was just making a note=
=20
that this needs to be fixed, otherwise some French or German person is goin=
g=20
to try bat with accented characters in the database and be upset that they=
=20
become illegible.

>=20
> >=20
> > Well, those are the main issues that I can think of for the moment.  An=
y=20
> > comments from you (Dirk) or anyone else are welcome.  I think the issue=
=20
that=20
> > worries me the most is the technical details of how to work with pages =
(a=20
> > StackedWidget) and yet be able to turn them into floating windows as on=
e=20
> > wants.
>=20
> I'm probably most worried about that also and wish I could be of more
> help here.  I think we need to look at existing applications and decide
> which one is most similar to what we are looking for as an end result.

Yes, agreed.  Dan gave a few nice examples.

> Then we should look at it's widget usage.  Take KDevelop as an example.
> (I know, it's kde as opposed to qt)  Dockable? tabbed widgets left right
> and bottom.  We have a lot we want to differentiate here.  Primarily
> directors connected to, secondarily different default views from the
> director.  Other querry related views that a user would request in the
> process of using.  Monitoring windows of currently running directors,
> file and storage daemons?

Yes, we need to implement all the above including Monitoring windows.

>=20
> I'd say we don't want to confuse the user.  All windows for one director
> should immediately be non viewable when another director is active.

I'm not sure we need to make that restriction.  With the page selector, onl=
y=20
one page can be viewable at a time, but there is no reason why multiple=20
directors could not be simultaneously connected.  Once we can float a page=
=20
above the main window, there is no reason why multiple directors should not=
=20
be viewable at the same time.  We just need some careful thought about havi=
ng=20
the Director (or other daemon) name in the window title so it is clear what=
=20
the user is viewing.

I think I need to add a few directors to the current code so that everyone =
can=20
see how easy this will really be.

> Maybe this is where the stacked widgets come in handy.

Yes, and the page selector is the key.  If you look carefully, you will=20
realize that all the pages that you can select are under a director.  Once =
I=20
add a second director, it will have an identical list of pages under it, ea=
ch=20
of which will have the same functionality but data from the director that i=
t=20
is under.  Likewise, we can all Client and Storage monitors, and they will=
=20
appear at the level of the current director, with the pages that are=20
appropriate to those daemons under them.

Best regards,

Kern