heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=65ee299a0c0e9044d809e58c3c5e75d05ad76f0e

tdf#114484 - Make internal file and print dialogs obsolete

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Simple access vi UI is hidden with the patch, Tools > Options > Advanced > Expert > org.openoffice.Office.Common.Misc > UseSystemFileDialog can still be used to enable or disable. Regardless this option the internal dialogs will also be shown for SAL_USE_VCLPLUGIN=gen and are relevant for headless mode.

Some code pointers to clean up later (would keep the ticket open):
svtools/source/config/miscopt.cxx
include/svtools/miscopt.hxx
cui/source/options/optgdlg.cxx
cui/source/options/optgdlg.hxx
desktop/source/app/app.cxx
svtools/source/uno/fpicker.cxx

The internal print dialog is still enabled, however the respective field is hidden with code.

OfaMiscTabPage::OfaMiscTabPage(vcl::Window* pParent, const SfxItemSet& rSet)
    : SfxTabPage(pParent, "OptGeneralPage", "cui/ui/optgeneralpage.ui", &rSet)
{
    get(m_pExtHelpCB, "exthelp");
    if (!lcl_HasSystemFilePicker())
        get<VclContainer>("filedlgframe")->Hide();
#if ! ENABLE_GTK
    get<VclContainer>("printdlgframe")->Hide();
#else
    if (!SvtMiscOptions().IsExperimentalMode())
    {
        get<VclContainer>("printdlgframe")->Hide();
    }
#endif

(In reply to Heiko Tietze from comment #0)
> Recommended in [1] and accepted in [2] the task is to remove the internal
> file and print dialogs because of 

There was no talk about removing the internal print dialog during the design meeting, or am i missing something.

heiko tietze committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd260a59cfdd050db3aa9a641ef0fa09efcedf5b&h=libreoffice-6-0

tdf#114484 - Make internal file and print dialogs obsolete

It will be available in 6.0.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Yousuf Philips (jay) from comment #3)
> There was no talk about removing the internal print dialog during the design
> meeting, or am i missing something.

Well, it's the same topic. But you are right, we didn't discuss and nothing has changed for the print dialog.

(In reply to Julien Nabet from comment #6)
> Heiko since a bugtracker at status ASSIGNED requires an assignee, having
> seen your patch I put you.
> Of course don't hesitate to revert if disagree.

Forgot to set back to NEW. Reverted intentionally since the next step before 6.1 or later might need more expertise than mine. And it's up to QA whether the ticket should stay open or not as the UI access is disabled now.

Hmm. I am bit torn about this issue

I agree that these dialogs should be ideally not used. Normal desktop integration will use system file dialogs. But what about print? Do we use the KDE print dialog?

Anyways, Heiko tells me on IRC that the plan is also to remove the internal code for these. There os where problems begin:

There is cases where you don't have the needed stuff:
 - nothing for kde5
 - file pickers disabled for kde4 at runtime with non-patched Qt4
 - gtk2 and gtk3 can both be disabled. Also can be in own packages.

So you might not have *any* of those. What are you then going to use?
Of course, one could inflict a gtk3 dependency here, but is it worth it? And will
LO then have a hard gtk3 dependency when people use a (prospective) gtk4 VCLPlug?

Enabling the system print dialog is currently an experimental feature, as it lacks some features [1], and it isn't available anywhere outside gtk2/gtk3. So removing it isn't an option.

[1] https://lists.freedesktop.org/archives/libreoffice/2017-April/077625.html

Don't see a difference when I check the internal print dialog option or not (using "gen" VCL). Bad usability, btw, to completely hide options - both internal dialogs are hidden depending on the setup.

Haven't counted the tickets at bug 103309 but there are a lot. At least for the internal file dialog I don't see progress to make them work. And for what reason? So my take is, after all Rene's concerns and since headless and gen use the internal file dialogs, that we strip down any additional functionality and dont even try to make them competitive with the system picker. Only the most important stuff should be kept.

(In reply to Heiko Tietze from comment #10)
> ... At least for
> the internal file dialog I don't see progress to make them work. And for
> what reason? So my take is, after all Rene's concerns and since headless and
> gen use the internal file dialogs, that we strip down any additional
> functionality and dont even try to make them competitive with the system
> picker. Only the most important stuff should be kept.

+1

This bug is marked All but from what I see discussion was chiefly about Linux. 
I may be off-topic with this, but let me bump this bug saying this:
In Windows 7 I have a folder with 5624 documents (surprise: it's LO bug docs).
LO is unable to sort this amount of files (by Date or by Name) from within File-Open dialog (shown with Details). 
Can't say why, but Save dialog works fine.

Hello all,

I found the idea of removing the internal LibreOffice dialog a really good idea but the current implementation makes it difficult to disable LibreOffice dialog.

A simple example:
1) Enable LibreOffice built-dialog with LibreOffice 4 or 5
2) Upgrade to Libreoffice 6.1
3) Try to disable LibreOffice built-in dialog

Result:
A regular user is now blocked on LibreOffice dialog without being able to to back on system dialog

Expected result:
It should be useful to restore this check box and enable a pop-up dialog that discourage users to enable it or just switch the LibreOffice dialog on upgrade

Keeping this current implementation seems difficult for beginners.

Thanks all for your involvement on LibreOffice to make it better everyday.

Best regards,
Alex.

(In reply to Alex ARNAUD from comment #13)
> 
> I found the idea of removing the internal LibreOffice dialog a really good
> idea but the current implementation makes it difficult to disable
> LibreOffice dialog.
> 
> A simple example:
> 1) Enable LibreOffice built-dialog with LibreOffice 4 or 5
> 2) Upgrade to Libreoffice 6.1
> 3) Try to disable LibreOffice built-in dialog
> 
> Result:
> A regular user is now blocked on LibreOffice dialog without being able to to
> back on system dialog
> 
> Expected result:
> It should be useful to restore this check box and enable a pop-up dialog
> that discourage users to enable it or just switch the LibreOffice dialog on
> upgrade
> 
> Keeping this current implementation seems difficult for beginners.

Valid point, but issue is with search function against stanzas in the Expert Configuration dialog. As in comment 2 here, the "UseSystemFileDialog" string will return the correct setting to toggle. Unfortunately there is no cursor movement between columns of the tree view in the dialog--impeding a11y. That specific issue is open against the Expert Configuration dialog as bug 99609

I for my part would like to keep those dialogs [file picker dialog] for one reason.

When using windows dialogs for export to pdf or similar functions, the last folder systemwide is opened, not the folder of the current document. This is quite annoying. Ubuntu users do not have this problem, though. ;-)

Libre office dialogs do open the current folder to save the pdf. That's the reason why I do keep using LO dialogs. And I am not free to choose the OS at work, so no I can't use Ubuntu here. :-)

(In reply to D.F. from comment #15)
> When using windows dialogs for export to pdf or similar functions, the last
> folder systemwide is opened, not the folder of the current document.

Wouldn't that be a bug? The Export to PDF function starts with the path set under Tools > Options > Path at Linux, which should also be the fact on Windows. It's not a matter of the dialog but how it's being initialized.

FYI: There are good reasons why the internal file dialog is not popular for devs.
But for a part of the users/use cases, it has advantages.

Therefor my advocacy in https://bugs.documentfoundation.org/show_bug.cgi?id=125908#c7 to bring the option to set it, back from the hidden word (expert config) to that of normal users, Options > LibreOffice > General.

(In reply to Cor Nouws from comment #17)
> FYI: There are good reasons why the internal file dialog is not popular for
> devs.
> But for a part of the users/use cases, it has advantages.
> 
> Therefor my advocacy in
> https://bugs.documentfoundation.org/show_bug.cgi?id=125908#c7 to bring the
> option to set it, back from the hidden word (expert config) to that of
> normal users, Options > LibreOffice > General.
Reading the minutes of Design and ESC, the idea is to remove if/when the functionalities can be replaced. Does hiding the feature during that process, make the process faster?

And why does this ticket talk about removing the internal Print Dialog. How serious is that? (joehoe, Bibli ;) )

(In reply to Cor Nouws from comment #18)
> Does hiding the feature during that process, make the process faster?

It's the way of deprecating a feature. IIRC, the internal dialog serves only KDE4 (done) and Gen, which may stay there forever. There is absolute no reason to implement a more usable file picker than OS'es does. At least we failed so far and should focus on office features.

I do not use internal dialogs, but in bug 133034 they work and system ones don't.