Comments on: !Windows

By: Eemil

Eemil — Thu, 27 Aug 2009 10:05:42 +0000

I agree with Tom:
Hiding information that enables you to make an informed decision on the dialog is why I for one move that dialog to the side.
“Do I want to save unnamed-1? Which one was that? Oh, its behind the dialog…”
This is why I really appreciate the gedit way, and the firefox way (the options for saving a password for the site roll down from the top of the content area), and the Pidgin connection error information that appears on the bottom of the buddy list, keeping the whole content still scrollable, not obscuring it. More solutions like these!

By: Alex Launi

Alex Launi — Thu, 27 Aug 2009 05:26:01 +0000

I used the one window principal for the tic tac toe game I wrote this weekend (launchpad.net/tictactoe, http://bit.ly/ETrHh). I had to use one dialog, because there are no python bindings to GTKInfoBar. I Tried to implement it myself but no dice.

The game came out really well done, and very elegant.

By: Tom

Tom — Thu, 27 Aug 2009 02:43:47 +0000

I agree the gedit should be a model (when they made the change to the infobar I instantly loved it). OSX should not be the model. Though their little animation looks slick and the basic idea is the same, the fact that they cover up your document is *really* frustrating. I use macs quite rarely, and I’ve run into the situation where this style interface put me in an impossible bind more than once. The problem is that the kinds of questions applications have to ask you very often have to do with the content that you are looking at, so if that content is obscured, you can get really annoyed (and on OSX there’s no way to hide the window, minimize it, etc., without answering the dialog)

By: Janne

Janne — Wed, 26 Aug 2009 22:31:32 +0000

@Will, thanks, that helps a bit. Didn’t know about that one. Still wish they could sinply not lock those dialogs to be on top. This way each application would end up with their own key combination for things like this.

By: Will

Will — Wed, 26 Aug 2009 12:37:33 +0000

@Janne, Re: hiding/showing panes in Inkscape: F12 hides/restores dialogs. I use it a lot at work in combination with F11 (fullscreen). It can on occasion be slightly buggy with several documents open and a combination of docked/undocked panes but mostly it works quite well.

By: Hylke

Hylke — Wed, 26 Aug 2009 11:28:28 +0000

Great ideas. I really like gedit for this reason. Overwriting, reloading, saving over a network, it’s all done in the infobar. Except for the search dialog, it should be more like how firefox does it.

By: Janne

Janne — Wed, 26 Aug 2009 09:12:18 +0000

@Mie, you need to see the object you’re manipulating, so being able to move the panes around is critical. I would really liek to see the function that can slide them in and out automagically without making it even more frustrating.

As it is, opening and closing the panes is a real hassle. There’s no shortcut key for closing as far as I know, so you have to use the mouse to hit the close button, and then you have to bring the panes up again, each with its own shortcut key. A lot of work when all you want is to have them go behind the workspace for a moment. It’s gotten to the point where I consider getting the source and patching it to get rid of this “always at the top” setting. Really – why is it there? Is anybody actually helped by having that set?

And the reality is that window switching, with Alt-Tab, already does what we need. It’s fast, it’s convenient, and it’s the same key for all applications. The one real improvement that apps like Gimp (or Inkscape, if they only let you do this) would be to have all the panes and semi-permanent dialogs in the same group, so that the opened dialogs all come to the front at once or go behind the work space at once.

By: Mie

Mie — Wed, 26 Aug 2009 07:44:10 +0000

@Janne: Object Preferences panes in Inkscape (for ex.) could automatically slide in and out to free space for the whole image.

By: kamstrup

kamstrup — Wed, 26 Aug 2009 07:11:45 +0000

Thanks for all the awesome comments everyone! There’s a lot of insight here I see

@jsled: The fact that almost every web app behaves like this is also a good pro-argument. General consistency with web apps is of course not attainable, but there are definitely some broad trends that we can adapt to. More consistency with web would be sweet!

@Faraone, Nick: I actually think that a lot of my window frustrations come from my experience with Sugar, Moblin, and Ubuntu Netbook Remix. They all take an approaches where the window=application to some extend, and I’ve just grown very used to this concept since it is so much easier to work with for most tasks.

@Shaun, Janne: First of all the sheets are for modal interactions so I need never *edit* anything underneath it. I might however want to *see* what is underneath it. This could be achieved in many ways, but some form of triggered translucency effect would probably be best… Unless one needs to copy-paste some text from the parent window (can I even do that from a normal modal dialog?). But the important thing is that I think this class of problems is solvable.

@Irwin: Yeah, I also think that the WM could magically convert modal dialogs to sheets. This might be better than hacking GtkDialog, but I suspect there are a lot of tricky interactions between tookit< ->WM…

By: Chris Irwin

Chris Irwin — Wed, 26 Aug 2009 04:12:52 +0000

In general I agree with having one application window.

But couldn’t things like modal dialog appearing as a slideout be something that could be handled by the window manager?