Page 1 of 1

Drag and drop should be a standard

Posted: Wed Mar 14, 2012 3:48 am
by finale00
I think drag and drop should be supported by any GUI application.
Any application that requires you to "choose a file" should support drag and drop.

Some applications are designed so that not only do you not have a BUTTON that you can click on to choose a file, but they force you to select a menubar to choose a menu option that prompts you to choose a file.

What are some things that every GUI application should have?

Re: Drag and drop should be a standard

Posted: Thu Mar 15, 2012 3:27 pm
by Mr.Mouse
Drag and drop really doesn't need to be with all GUI, it depends on the purpose of the tool. Why would you want it?
finale00 wrote: What are some things that every GUI application should have?
1. A quit button. :D
2. Check file existing if trying to save work and warn the user. (I sometimes come across tools that don't do this. What a load of crap after you suddenly realize you clicked "save" instead of "load" in otherwise similar dialogs)
3. Clearly separated Load and Save buttons, if needed
4. A decent file manager dialog

Just some things, there are many more

Re: Drag and drop should be a standard

Posted: Wed May 30, 2012 3:13 pm
by spont
What I'd like... from a utopian perspective...

Mr.Mouse wrote: 1. A quit button. :D
I'd like a system-wide option to disable the "do you really REALLY want to quit?" dialogs when there is no unsaved data. Or better still - since storage is cheap - backup any unsaved data automatically and quit. I.e. automatically store application state which can be resumed, bookmarked or reset.

Mr.Mouse wrote: 2. Check file existing if trying to save work and warn the user. (I sometimes come across tools that don't do this. What a load of crap after you suddenly realize you clicked "save" instead of "load" in otherwise similar dialogs)
Revision Control at the file-system level would let you recover from that situation.

Mr.Mouse wrote: 4. A decent file manager dialog
I'd like to get rid of files altogether, and just deal with cross-referenced Data. Any file containing more than one section of Data could legitimately be split into multiple files, so it seems to me that the concept of a file itself is the same as any other archive. It's a convenient work-around, and contributing factor to the problem that your computer will likely have no clue as to the Data inside a file with a wrong three-letter extension.

With the Data-Orientated method you'd first identify the Data, extract it to a database and tag it. Then instead of a file manager dialog you'd have a Data Search dialog, where the original filename is just one searchable parameter. If the Data is part of a larger set (e.g. a palette paired with an image), then the dialog would expand to let you select the cross-references.

I can dream :-)

A more achievable compromise in the short-term would be to have the option to impose your favourite file manager dialog on any application.