shell dialogs: Move the linux implementations.

shell dialogs: Move the linux implementations.

This moves the gtk and kde implementations to a common directory so a search will get all the code when we need to remove the normal gtk port.

This isn't a pure move. Parts of SelectFileDialogImplKDE had to be rewritten to not use BrowserThread.

BUG=134529
TEST=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=148235

[Elliot Glaysher, 2012-07-19 23:51:36]

The versions here in ui/base/dialogs/gtk/ are temporary for a few months until
the linux_aura build is the default. (I'll be doing another copy of this code,
this time without modification into the linux_aura libgtk2ui target.)

ajwong: could you please review the transition from BrowserThread to WorkerPool
in the KDE files?
thestig: general review
sky: stamp

[Lei Zhang, 2012-07-20 00:18:59]

lgtm

[awong, 2012-07-20 00:25:52]

Not sure why I'm qualified for a KDE review, but module the comment below, basic
code looks okay.

Why are we moving from FILE thread to WorkerPool though? Are there any
ramifications from running on a non-joined thread?

https://chromiumcodereview.appspot.com/10790083/diff/1/ui/base/dialogs/gtk/se...
File ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc (right):

https://chromiumcodereview.appspot.com/10790083/diff/1/ui/base/dialogs/gtk/se...
ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc:255:
params.ui_loop->PostTask(FROM_HERE,
With BrowserThread, if the thread was dead, it would just drop the task. Here, I
think you segv or do a use-after-free.  Are we guaranteed ui_loop will exist? 
If not, maybe MessageLoopProxy is better?

[sky, 2012-07-20 15:29:13]

LGTM

[Elliot Glaysher, 2012-07-20 17:06:50]

On 2012/07/20 00:25:52, awong wrote:
> Why are we moving from FILE thread to WorkerPool though? Are there any
> ramifications from running on a non-joined thread?

(I picked you since your name came up in a lot of WorkerPool stuff.)

I have to move off content::BrowserThread because content:: can't be accessed
from ui::, but the file selection dialog code needs to live in ui/. If there's a
better interface for posting future tasks that run on a non-blocking thread, I'd
be happy to use that instead.

https://chromiumcodereview.appspot.com/10790083/diff/1/ui/base/dialogs/gtk/se...
File ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc (right):

https://chromiumcodereview.appspot.com/10790083/diff/1/ui/base/dialogs/gtk/se...
ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc:255:
params.ui_loop->PostTask(FROM_HERE,
On 2012/07/20 00:25:52, awong wrote:
> With BrowserThread, if the thread was dead, it would just drop the task. Here,
I
> think you segv or do a use-after-free.  Are we guaranteed ui_loop will exist? 
> If not, maybe MessageLoopProxy is better?


Switched to a MessageLoopProxy.

[awong, 2012-07-24 17:48:32]

LGTM w/ nit

https://chromiumcodereview.appspot.com/10790083/diff/13001/ui/base/dialogs/gt...
File ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc (right):

https://chromiumcodereview.appspot.com/10790083/diff/13001/ui/base/dialogs/gt...
ui/base/dialogs/gtk/select_file_dialog_impl_kde.cc:99: // Call KDialog on the
FILE thread and post results back to the UI thread.
Update this comment please.  I think it should say something like "must be
called on the worker thread" since the caller does all the thread
management...unless you refactor it so the thread-bounce happens under this API.