LÖVE

Just changing ffi.load 'gtk-3' to ffi.load 'gtk-x11-2.0.so' worked for me (the .so is necessary because there's a dot in the name)

I hope nobody still uses KDE...

I much prefer it over Gnome.

pgimeno wrote:Just changing ffi.load 'gtk-3' to ffi.load 'gtk-x11-2.0.so' worked for me (the .so is necessary because there's a dot in the name)

Nice, that works for me too.

I much prefer [KDE] over Gnome.

I used to prefer it also, but that was maybe 10 years ago; gnome has improved a lot now and I wasn't sure KDE was still relevant. I guess since we just got GTK2 for free we can do a QT dialog

airstruck wrote:I used to prefer it also, but that was maybe 10 years ago; gnome has improved a lot now and I wasn't sure KDE was still relevant. I guess since we just got GTK2 for free we can do a QT dialog

Trying hard to not derail the thread

I'd love to see a QT dialog. I'll leave it at that

SiENcE wrote:Here you go:

Windows OpenFile Dialogue - (tested on Windows 7 64bit)

Code: Select all

ffi = require"ffi"
bit = require"bit"

collectgarbage("stop")

ffi.cdef[[
  static const int OFN_FILEMUSTEXIST             = 0x1000;
  static const int OFN_NOCHANGEDIR               = 8;
  static const int OFN_PATHMUSTEXIST             = 0x800;

  typedef bool BOOL;
  typedef char CHAR;

  typedef unsigned short WORD; 
  typedef unsigned long DWORD;

  typedef void *PVOID;
  typedef void *LPVOID;
  typedef void *LPOFNHOOKPROC;

  typedef unsigned long HANDLE;
  typedef HANDLE HWND;
  typedef HANDLE HINSTANCE;

  typedef const char *LPCSTR;
  typedef const char *LPCTSTR;

  typedef char *LPSTR;
  typedef char *LPTSTR;

  typedef unsigned long LPARAM;

  typedef struct {
    DWORD         lStructSize;
    HWND          hwndOwner;
    HINSTANCE     hInstance;
    LPCTSTR       lpstrFilter;
    LPTSTR        lpstrCustomFilter;
    DWORD         nMaxCustFilter;
    DWORD         nFilterIndex;
    LPTSTR        lpstrFile;
    DWORD         nMaxFile;
    LPTSTR        lpstrFileTitle;
    DWORD         nMaxFileTitle;
    LPCTSTR       lpstrInitialDir;
    LPCTSTR       lpstrTitle;
    DWORD         flags;
    WORD          nFileOffset;
    WORD          nFileExtension;
    LPCTSTR       lpstrDefExt;
    LPARAM        lCustData;
    LPOFNHOOKPROC lpfnHook;
    LPCTSTR       lpTemplateName;

    LPVOID        pvReserved;
    DWORD         dwReserved;
    DWORD         flagsEx;

  }OPENFILENAME;

  BOOL GetSaveFileNameA( OPENFILENAME lpofn );
  BOOL GetOpenFileNameA( OPENFILENAME *lpofn );
]]
com=ffi.load("comdlg32")

ffi.cdef[[
  DWORD GetLastError(void);
]]
krnl=ffi.load("kernel32")

function OpenDialog()
  Ofn=ffi.new("OPENFILENAME")
  ffi.fill(Ofn,ffi.sizeof(Ofn)) --zero fill the structure

  local szFile        = ffi.new("char[260]","\0")
  local hwnd          = ffi.new("HWND",0)

  Ofn.lStructSize     = ffi.sizeof(Ofn)
  Ofn.hwndOwner       = hwnd

  Ofn.lpstrFile       = szFile
  Ofn.nMaxFile        = ffi.sizeof(szFile)

  Ofn.lpstrFilter     = "All\0*.*\0Text\0*.TXT\0"
  Ofn.nFilterIndex    = 1

  Ofn.lpstrFileTitle  = nil
  Ofn.nMaxFileTitle   = 0

  Ofn.lpstrInitialDir = nil
  Ofn.flags           = bit.bor(com.OFN_PATHMUSTEXIST, com.OFN_FILEMUSTEXIST, com.OFN_NOCHANGEDIR)

  print("displaying...")

  if com.GetOpenFileNameA(Ofn) then --luajit converts bool automatically
    print("file->",ffi.string(Ofn.lpstrFile, Ofn.nMaxFile))
  end

  print("lasterror->",krnl.GetLastError())
end

function love.keypressed(key, code)
	if key == 'o' then
		OpenDialog()
	end
end

Doesn't seem to work anymore on Win10, I get a CDERR_STRUCTSIZE (https://msdn.microsoft.com/en-us/librar ... s.85).aspx) error upon a CommDlgExtendedError call. Although nothing seems to work for the lStructSize parameter.

Leave it to microsoft to take a one line api call and turn it into a com-plicated nightmare.

[Starting with Windows Vista, the Open and Save As common dialog boxes have been superseded by the Common Item Dialog. We recommended that you use the Common Item Dialog API instead of these dialog boxes from the Common Dialog Box Library.]

Wrapped their example common item dialog code in a vanilla dll with two exports; DialogOpen and DialogSave. While they are modal and block love2d, they seem to work fine even if invoked in, say, the love.keyreleased handler. However not sure how this will affect love2d if a dialog is left open for long periods (love2d being unable to clear windows message queue; events stack up and get processed when the dialog is closed). It would be nice to eventually have an option to make them non-modal; any way to do that without having an entirely separate process pop the dialog box?

Finally, having forgotten more than i remember about COM, wanted to ask if love2d uses it in the windows build, and if so, what would be the most appropriate/compatible flags for CoCreateInstance, and whether there are any compiler options that matter (right now it is just visual code's defaults for a multithreaded c++14 dll with __cdecl function exports).

Sounds like you did a lot of work on this years-old thread.

I might be mistaken, but I think I read somewhere that the next release of Love will allow access to the entire filesystem. This would mean a simple love/lua library can be written to achieve the same goal of having a cross-platform file chooser dialog. Can anyone else confirm that?

yes, couldn't resist the necro, though ended up here from a bit newer comment! while porting old utility back to windows i found SiENcE's method no longer works and was rooting around for the cause

viewtopic.php?p=248036#p248036

I think I read somewhere that the next release of Love will allow access to the entire filesystem

sounds awesome, if true i'm looking forward to never again mucking around in windows / com junk!

a lot of work

nah, just copy and paste from example below into empty dll project and comment out some lines.

https://github.com/microsoft/Windows-cl ... filedialog

real work would be turning the hack into something worth posting (i.e. supporting various dialog flags, converting windows ucs-2 encoding), which, if love is getting file dialogs, won't be worth the effort. mainly wanted to share what the underlying issue was with earlier method as well as see if anyone had better ideas on how to make a (native) non-modal file selection system.

yal2du wrote: ↑Tue Sep 13, 2022 3:23 pm ... which, if love is getting file dialogs, won't be worth the effort...

I don't think it's getting file dialogs - just the ability to access the full filesystem. Again, that's IIRC - can't find my source right now. But from that, it would be "easy enough" to build what you want in lua without delving into FFI.

milon wrote: ↑Tue Sep 13, 2022 12:52 pm I might be mistaken, but I think I read somewhere that the next release of Love will allow access to the entire filesystem. This would mean a simple love/lua library can be written to achieve the same goal of having a cross-platform file chooser dialog. Can anyone else confirm that?

This is true. However native OS file dialogs can look nicer in some situations and might give more (potentially idiomatic platform-specific) features that users expect, compared to a single implementation across all platforms.

slime wrote: ↑Tue Sep 13, 2022 5:47 pm This is true. However native OS file dialogs can look nicer in some situations and might give more (potentially idiomatic platform-specific) features that users expect, compared to a single implementation across all platforms.

Absolutely! Is that a potential feature we can expect then? I just didn't think it was going to happen. I'd be happy to be wrong though.