Is search dialog really a dialog?
Jiri Palecek
The GNOME HIG says
Use a dialog to obtain additional information from the user that is
needed to carry out a particular command or task.
The KDE HIG says on the same topic
A complex dialog is a dialog that allows the user to fine-tune an
operation
But does the search dialog really do that? I'd say no, because it does
not fine-tune the operation -- it DOES an operation.
Why was I writing such philosophic blurbs?
The problem is that when you press F3 on the filelist, the viewer opens
obscured below the dialog. It is a tough job, or even impossible to
move
the dialog below it (I usually move it out from the screen, which is
not
really good).
Reagrds
Jiri Palecek
Shie Erlich
how would you suggest to approach the search issue?
--
Shie Erlich
http://www.krusader.org/
Jiri Palecek
Non-modal window :-)
Maybe this video
http://www.ms.mff.cuni.cz/~palej3am/test.html
can somewhat illuminate the problem. (very poor quality, but only 130
kB)
Regards
Jiri Palecek
Shie Erlich
well, the url didn't quite produce what i expected.
only two combo boxes.
Jiri Palecek
> >
> > http://www.ms.mff.cuni.cz/~palej3am/test.html
> >
> > can somewhat illuminate the problem. (very poor quality, but only 130
> > kB)
>
>
>
> well, the url didn't quite produce what i expected.
> only two combo boxes.
Sorry, I have copied bad url. This time it should be better
http://www.ms.mff.cuni.cz/~palej3am/scrn2.ogg
Regards
Jiri Palecek
Karai Csaba
That's why you can search / pack / synchronize in the background...
Csaba
Jiri Palecek
Karai Csaba wrote:
> Yes. The searcher, packer, synchronizer widgets are non-modals.
>
> That's why you can search / pack / synchronize in the background...
But being a dialog (or WM_TRANSIENT_FOR the main window), you
cannot move them behind the main widget and/or minimize them
without minimizing the main widget.
Regards
Jiri Palecek
Shie Erlich
i'm able to put krusader to the forground easily. just alt-tab and that's it.
Jiri Palecek
This greatly depends on the windowmanager you're using. In kwm (or
what the KDE default is called), it works. I use openbox and it
doesn't work there. Neither does in metacity, the gnome default.
Even Qt documentation says that dialogs share their taskbar entry with
their parent -- which is what kwm fails to do. If it shared, it would
not be possible to switch to krusader. You could somewhat ameliorate
the situation by making the viewer NOT child of krusader. You can
switch to viewer then but not to krsader (or, to be more precise -- you
can switch everywhere, but the dialog is still shown in front).
Regards
Jiri Palecek
Shie Erlich
Dirk Eschler
You can see a difference with kwin too:
- (Un)pack something big to ensure that the packing dialog is visible
- Minimize Krusader's main window (both windows get minimized)
- Raise the main window and the packer window is raised as well (IMHO that
shouldn't be the case)
bye,
Dirk
--
Dirk Eschler <mailto:dirk.e...@gmx.net>
http://www.krusader.org
Dirk Eschler
Err ok, this thread was about the search dialog... :|
Jiri Palecek
Hello.
Well, the WM name is openbox. A patch which "somewhat ameliorates",
eg. does not solve the problem completely, is at
http://www.ms.mff.cuni.cz/~palej3am/krusader_dialog.patch
It merely changes the parent of the viewer. Maybe (I'm not sure),
changing the flags in the constructor is unnecessary.
Regards
Jiri Palecek
Shie Erlich
sorry for taking so long. lost in the mail...
i applied the patch, without the constuctor stuff. i'd appriciate if you
tell me if it works without changing the flags.
although, if it does work, it still has no bearing on the search dialog situation right?
thanks
--
http://www.krusader.org/
Jiri Palecek
Shie Erlich napsal:
> On 9/25/06, Jiri Palecek <jpal...@web.de> wrote:
> > Shie Erlich wrote:
> > > On 9/8/06, Jiri Palecek <jpal...@web.de> wrote:
> > > > Shie Erlich wrote:
> > > > > On 8/29/06, Jiri Palecek <jpal...@web.de> wrote:
> > > > > > Karai Csaba wrote:
> > > i never knew that was a problem, since i didn't use other window
> > managers.
> > >
> > > can you provide a patch to the way it does work on openwm or whatever wm
> > you
> > > do use?
> >
> > Hello.
> >
> > Well, the WM name is openbox. A patch which "somewhat ameliorates",
> > eg. does not solve the problem completely, is at
> >
> > http://www.ms.mff.cuni.cz/~palej3am/krusader_dialog.patch
> >
> > It merely changes the parent of the viewer. Maybe (I'm not sure),
> > changing the flags in the constructor is unnecessary.
>
> situation right?
Yes. This is why I say it only "somewhat" improves the situation. The
problem
is that "Dialogs stay before their parents", which means in this case
that the
search dialog would stay before the main krusader widget all the time.
The patch doesn't change that in any way. It does change the situation
of the
viewer. Before, it was a child of the krusader main widget, and because
of that, it would be behind the dialog as well. After, it is a normal
top-level
window with no parent, which has nothing to do with the dialog.
Therefore,
it won't stay behind the dialog.
However, there could be more changes to the dialog. For example, I
could
imagine (pure sci-fi) that the dialog would only have the "set-up"
part,
and the results part would open in the main krusader widget (for
example,
like "find in files" in KDevelop in IDEAl mode). What would you think
about it?
Reagrds
Jiri Palecek
Jiri Palecek
Shie Erlich napsal:
Yes, but...
> although, if it does work, it still has no bearing on the search dialog
> situation right?
... I have forgotten to include the SearchDialog part as well (eg. make
it a child of Krusader). This is because I have quite different
Krusader
and it is difficult to select the right changes for the patch, I'm
sorry.
The rest of the patch is at
http://www.ms.mff.cuni.cz/~palej3am/krusader_dialog2.patch
Regards
Jiri Palecek