2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2010-03-21 01:14:04 +00:00
|
|
|
* $Id$
|
2009-01-06 14:42:54 +00:00
|
|
|
*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-01-06 14:42:54 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-27 20:29:51 +00:00
|
|
|
/** \file blender/editors/space_file/file_draw.c
|
|
|
|
* \ingroup spfile
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2010-12-15 15:56:06 +00:00
|
|
|
#include <math.h>
|
2009-01-06 16:15:43 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
#include "BLI_blenlib.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BLI_utildefines.h"
|
2009-03-14 05:21:57 +00:00
|
|
|
#include "BLI_dynstr.h"
|
2009-01-06 14:42:54 +00:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "BLI_winstuff.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include "BIF_gl.h"
|
|
|
|
#include "BIF_glutil.h"
|
|
|
|
|
|
|
|
#include "BKE_context.h"
|
|
|
|
#include "BKE_global.h"
|
2010-10-18 06:41:16 +00:00
|
|
|
#include "BKE_main.h"
|
2009-01-06 14:42:54 +00:00
|
|
|
|
2009-05-14 18:54:41 +00:00
|
|
|
#include "BLF_api.h"
|
2011-09-20 07:39:25 +00:00
|
|
|
#include "BLF_translation.h"
|
2009-05-14 18:08:14 +00:00
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
#include "IMB_imbuf_types.h"
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
BugFix:
[#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders
Blenfont was not thread safe, that is why one thread can change
the font properties (size, dpi, color, etc) at the same time
that the stamp draw on the image, and then the problem.
To make blenfont thread safe I have to change two important things:
1) Every BLF_* function take one argument, the font id.
2) We have two new function to make font "thread safe":
BLF_load_unique
BLF_load_mem_unique
This two function are for case like stamp, that need and own font
that don't share the glyph cache, so can draw without problem
in a different thread.
Why the BLF_*_unique function ?
Because blenfont keep only one copy of a font and keep a list of
"glyph cache". Every glyph cache have size and dpi, so if two
different thread access the same font at the same time, they can
change value and finish with something like the stamp problem.
Why don't remove the glyph cache ?
Because if we do that, we finish with a font object for every size
and dpi, and the stamp is really a special case that happen in
the rendering process, so I really thing is better keep the
glyph cache and make this two new function to handle this
special case.
(When I say "font object" I mean have the same freetype font multiple
times just to have differents size and dpi)
As Matt point we still can have one case that two thread access
the BLF_*_unique function at the same time, but I am looking to
fix this with some class of thread lock.
For now I test and work fine, so if some one found problem, please
let me know.
Campbell I have to change the python api (python/generic/blf_api.c)
to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
|
|
|
#include "DNA_userdef_types.h"
|
2009-01-06 14:42:54 +00:00
|
|
|
|
|
|
|
#include "RNA_access.h"
|
|
|
|
|
2009-01-06 18:14:37 +00:00
|
|
|
#include "ED_fileselect.h"
|
|
|
|
#include "ED_screen.h"
|
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
#include "UI_interface.h"
|
|
|
|
#include "UI_interface_icons.h"
|
|
|
|
#include "UI_resources.h"
|
|
|
|
#include "UI_view2d.h"
|
|
|
|
|
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
|
|
#include "fsmenu.h"
|
|
|
|
#include "filelist.h"
|
|
|
|
|
|
|
|
#include "file_intern.h" // own include
|
|
|
|
|
|
|
|
/* button events */
|
2011-02-17 22:34:41 +00:00
|
|
|
enum {
|
2009-07-10 17:05:04 +00:00
|
|
|
B_FS_DIRNAME,
|
|
|
|
B_FS_FILENAME
|
2011-02-17 12:05:09 +00:00
|
|
|
} /*eFile_ButEvents*/;
|
2009-01-06 14:42:54 +00:00
|
|
|
|
2009-03-10 23:14:41 +00:00
|
|
|
|
2010-10-16 08:03:28 +00:00
|
|
|
static void do_file_buttons(bContext *C, void *UNUSED(arg), int event)
|
2009-01-06 14:42:54 +00:00
|
|
|
{
|
|
|
|
switch(event) {
|
2009-07-10 17:05:04 +00:00
|
|
|
case B_FS_FILENAME:
|
|
|
|
file_filename_exec(C, NULL);
|
|
|
|
break;
|
|
|
|
case B_FS_DIRNAME:
|
|
|
|
file_directory_exec(C, NULL);
|
|
|
|
break;
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-10 17:26:19 +00:00
|
|
|
/* Note: This function uses pixelspace (0, 0, winx, winy), not view2d.
|
|
|
|
* The controls are laid out as follows:
|
|
|
|
*
|
|
|
|
* -------------------------------------------
|
|
|
|
* | Directory input | execute |
|
|
|
|
* -------------------------------------------
|
|
|
|
* | Filename input | + | - | cancel |
|
|
|
|
* -------------------------------------------
|
|
|
|
*
|
|
|
|
* The input widgets will stretch to fill any excess space.
|
|
|
|
* When there isn't enough space for all controls to be shown, they are
|
|
|
|
* hidden in this order: x/-, execute/cancel, input widgets.
|
|
|
|
*/
|
2009-01-06 14:42:54 +00:00
|
|
|
void file_draw_buttons(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-07-10 17:26:19 +00:00
|
|
|
/* Button layout. */
|
2009-09-28 12:10:23 +00:00
|
|
|
const int max_x = ar->winx - 10;
|
2011-10-03 04:48:14 +00:00
|
|
|
const int line1_y = ar->winy - (IMASEL_BUTTONS_HEIGHT/2 + IMASEL_BUTTONS_MARGIN);
|
|
|
|
const int line2_y = line1_y - (IMASEL_BUTTONS_HEIGHT/2 + IMASEL_BUTTONS_MARGIN);
|
2009-09-28 12:10:23 +00:00
|
|
|
const int input_minw = 20;
|
|
|
|
const int btn_h = UI_UNIT_Y;
|
|
|
|
const int btn_fn_w = UI_UNIT_X;
|
|
|
|
const int btn_minw = 80;
|
|
|
|
const int btn_margin = 20;
|
|
|
|
const int separator = 4;
|
2009-07-10 17:26:19 +00:00
|
|
|
|
|
|
|
/* Additional locals. */
|
2010-08-26 07:26:13 +00:00
|
|
|
char name[32];
|
2009-09-28 12:10:23 +00:00
|
|
|
int loadbutton;
|
|
|
|
int fnumbuttons;
|
2010-01-18 03:36:19 +00:00
|
|
|
int min_x = 10;
|
2010-04-19 04:39:01 +00:00
|
|
|
int chan_offs = 0;
|
2009-09-28 12:10:23 +00:00
|
|
|
int available_w = max_x - min_x;
|
|
|
|
int line1_w = available_w;
|
|
|
|
int line2_w = available_w;
|
2009-07-10 17:26:19 +00:00
|
|
|
|
|
|
|
uiBut* but;
|
|
|
|
uiBlock* block;
|
2009-07-28 16:46:14 +00:00
|
|
|
SpaceFile* sfile = CTX_wm_space_file(C);
|
2009-01-08 18:47:16 +00:00
|
|
|
FileSelectParams* params = ED_fileselect_get_params(sfile);
|
2010-01-18 03:36:19 +00:00
|
|
|
ARegion* artmp;
|
2009-07-10 17:26:19 +00:00
|
|
|
|
|
|
|
/* Initialize UI block. */
|
2010-12-03 01:52:28 +00:00
|
|
|
sprintf(name, "win %p", (void *)ar);
|
2.5
More cleanup!
- removed old UI font completely, including from uiBeginBlock
- emboss hints for uiBlock only have three types now;
Regular, Pulldown, or "Nothing" (only icon/text)
- removed old font path from Userdef
- removed all old button theme hinting
- removed old "auto block" to merge buttons in groups
(was only in use for radiosity buttons)
And went over all warnings. One hooray for make giving clean output :)
Well, we need uniform definitions for warnings, so people at least fix
them... here's the real bad bugs I found:
- in mesh code, a call to editmesh mixed *em and *me
- in armature, ED_util.h was not included, so no warnings for wrong call
to ED_undo_push()
- The extern Py api .h was not included in the bpy_interface.c, showing
a several calls using different args.
Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
|
|
|
block = uiBeginBlock(C, ar, name, UI_EMBOSS);
|
2009-01-06 14:42:54 +00:00
|
|
|
uiBlockSetHandleFunc(block, do_file_buttons, NULL);
|
2010-01-18 03:36:19 +00:00
|
|
|
|
|
|
|
/* exception to make space for collapsed region icon */
|
|
|
|
for (artmp=CTX_wm_area(C)->regionbase.first; artmp; artmp=artmp->next) {
|
|
|
|
if (artmp->regiontype == RGN_TYPE_CHANNELS && artmp->flag & RGN_FLAG_HIDDEN) {
|
2010-04-19 04:39:01 +00:00
|
|
|
chan_offs = 16;
|
|
|
|
min_x += chan_offs;
|
|
|
|
available_w -= chan_offs;
|
2010-01-18 03:36:19 +00:00
|
|
|
}
|
|
|
|
}
|
2009-07-10 17:26:19 +00:00
|
|
|
|
|
|
|
/* Is there enough space for the execute / cancel buttons? */
|
|
|
|
loadbutton = UI_GetStringWidth(sfile->params->title) + btn_margin;
|
|
|
|
if (loadbutton < btn_minw) {
|
|
|
|
loadbutton = MAX2(btn_minw,
|
2010-03-22 09:30:00 +00:00
|
|
|
btn_margin + UI_GetStringWidth(params->title));
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
2009-07-10 17:26:19 +00:00
|
|
|
|
|
|
|
if (available_w <= loadbutton + separator + input_minw
|
|
|
|
|| params->title[0] == 0) {
|
|
|
|
loadbutton = 0;
|
|
|
|
} else {
|
|
|
|
line1_w -= (loadbutton + separator);
|
|
|
|
line2_w = line1_w;
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
2009-07-10 17:26:19 +00:00
|
|
|
/* Is there enough space for file number increment/decrement buttons? */
|
|
|
|
fnumbuttons = 2 * btn_fn_w;
|
|
|
|
if (!loadbutton || line2_w <= fnumbuttons + separator + input_minw) {
|
|
|
|
fnumbuttons = 0;
|
|
|
|
} else {
|
|
|
|
line2_w -= (fnumbuttons + separator);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Text input fields for directory and file. */
|
|
|
|
if (available_w > 0) {
|
2010-09-17 09:27:31 +00:00
|
|
|
int overwrite_alert= file_draw_check_exists(sfile);
|
|
|
|
/* callbacks for operator check functions */
|
|
|
|
uiBlockSetFunc(block, file_draw_check_cb, NULL, NULL);
|
|
|
|
|
2010-11-06 16:09:12 +00:00
|
|
|
but = uiDefButTextO(block, TEX, "FILE_OT_directory", 0, "",
|
2010-04-19 04:39:01 +00:00
|
|
|
min_x, line1_y, line1_w-chan_offs, btn_h,
|
2011-10-15 05:01:47 +00:00
|
|
|
params->dir, 0.0, (float)FILE_MAX, 0, 0,
|
2011-10-20 20:38:26 +00:00
|
|
|
TIP_("File path"));
|
2009-07-10 19:19:54 +00:00
|
|
|
uiButSetCompleteFunc(but, autocomplete_directory, NULL);
|
2010-08-28 12:34:22 +00:00
|
|
|
uiButSetFlag(but, UI_BUT_NO_UTF8);
|
|
|
|
|
2011-06-24 03:30:50 +00:00
|
|
|
if((params->flag & FILE_DIRSEL_ONLY) == 0) {
|
|
|
|
but = uiDefBut(block, TEX, B_FS_FILENAME, "",
|
|
|
|
min_x, line2_y, line2_w-chan_offs, btn_h,
|
2011-10-15 05:01:47 +00:00
|
|
|
params->file, 0.0, (float)FILE_MAXFILE, 0, 0,
|
2011-10-20 20:38:26 +00:00
|
|
|
TIP_(overwrite_alert ?N_("File name, overwrite existing") : N_("File name")));
|
2011-06-24 03:30:50 +00:00
|
|
|
uiButSetCompleteFunc(but, autocomplete_file, NULL);
|
|
|
|
uiButSetFlag(but, UI_BUT_NO_UTF8);
|
|
|
|
|
|
|
|
/* check if this overrides a file and if the operator option is used */
|
|
|
|
if(overwrite_alert) {
|
|
|
|
uiButSetFlag(but, UI_BUT_REDALERT);
|
|
|
|
}
|
2010-09-17 09:27:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* clear func */
|
|
|
|
uiBlockSetFunc(block, NULL, NULL, NULL);
|
2009-07-10 17:26:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Filename number increment / decrement buttons. */
|
2011-06-24 03:30:50 +00:00
|
|
|
if (fnumbuttons && (params->flag & FILE_DIRSEL_ONLY) == 0) {
|
2009-07-10 17:26:19 +00:00
|
|
|
uiBlockBeginAlign(block);
|
2009-07-12 08:12:22 +00:00
|
|
|
but = uiDefIconButO(block, BUT, "FILE_OT_filenum", 0, ICON_ZOOMOUT,
|
2011-10-20 20:38:26 +00:00
|
|
|
min_x + line2_w + separator - chan_offs, line2_y,
|
|
|
|
btn_fn_w, btn_h,
|
|
|
|
TIP_("Decrement the filename number"));
|
2009-07-10 17:26:19 +00:00
|
|
|
RNA_int_set(uiButGetOperatorPtrRNA(but), "increment", -1);
|
2009-03-09 08:31:45 +00:00
|
|
|
|
2011-10-20 20:38:26 +00:00
|
|
|
but = uiDefIconButO(block, BUT, "FILE_OT_filenum", 0, ICON_ZOOMIN,
|
|
|
|
min_x + line2_w + separator + btn_fn_w - chan_offs, line2_y,
|
|
|
|
btn_fn_w, btn_h,
|
|
|
|
TIP_("Increment the filename number"));
|
2009-07-10 17:26:19 +00:00
|
|
|
RNA_int_set(uiButGetOperatorPtrRNA(but), "increment", 1);
|
|
|
|
uiBlockEndAlign(block);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Execute / cancel buttons. */
|
2009-01-06 14:42:54 +00:00
|
|
|
if(loadbutton) {
|
2010-01-20 12:28:33 +00:00
|
|
|
|
|
|
|
uiDefButO(block, BUT, "FILE_OT_execute", WM_OP_EXEC_REGION_WIN, params->title,
|
|
|
|
max_x - loadbutton, line1_y, loadbutton, btn_h,
|
|
|
|
params->title);
|
2011-10-20 20:38:26 +00:00
|
|
|
uiDefButO(block, BUT, "FILE_OT_cancel", WM_OP_EXEC_REGION_WIN, IFACE_("Cancel"),
|
2010-01-20 12:28:33 +00:00
|
|
|
max_x - loadbutton, line2_y, loadbutton, btn_h,
|
2011-10-20 20:38:26 +00:00
|
|
|
TIP_("Cancel"));
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
2009-07-10 17:26:19 +00:00
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
uiEndBlock(C, block);
|
|
|
|
uiDrawBlock(C, block);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-09-28 12:10:23 +00:00
|
|
|
static void draw_tile(int sx, int sy, int width, int height, int colorid, int shade)
|
2009-07-10 17:05:04 +00:00
|
|
|
{
|
2009-01-18 18:24:11 +00:00
|
|
|
UI_ThemeColorShade(colorid, shade);
|
2011-09-11 06:41:09 +00:00
|
|
|
uiSetRoundBox(UI_CNR_ALL);
|
2011-04-10 09:37:04 +00:00
|
|
|
uiRoundBox((float)sx, (float)(sy - height), (float)(sx + width), (float)sy, 5.0f);
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-03-09 08:31:45 +00:00
|
|
|
static int get_file_icon(struct direntry *file)
|
|
|
|
{
|
2009-10-26 11:03:12 +00:00
|
|
|
if (file->type & S_IFDIR) {
|
|
|
|
if ( strcmp(file->relname, "..") == 0) {
|
|
|
|
return ICON_FILE_PARENT;
|
|
|
|
}
|
2010-03-15 20:28:13 +00:00
|
|
|
if(file->flags & BLENDERFILE) {
|
|
|
|
return ICON_FILE_BLEND;
|
|
|
|
}
|
2009-03-09 08:31:45 +00:00
|
|
|
return ICON_FILE_FOLDER;
|
2009-10-26 11:03:12 +00:00
|
|
|
}
|
2009-03-09 08:31:45 +00:00
|
|
|
else if (file->flags & BLENDERFILE)
|
|
|
|
return ICON_FILE_BLEND;
|
2011-01-30 13:12:03 +00:00
|
|
|
else if (file->flags & BLENDERFILE_BACKUP)
|
|
|
|
return ICON_FILE_BLEND;
|
2009-03-09 08:31:45 +00:00
|
|
|
else if (file->flags & IMAGEFILE)
|
|
|
|
return ICON_FILE_IMAGE;
|
|
|
|
else if (file->flags & MOVIEFILE)
|
|
|
|
return ICON_FILE_MOVIE;
|
|
|
|
else if (file->flags & PYSCRIPTFILE)
|
2009-03-11 23:22:07 +00:00
|
|
|
return ICON_FILE_SCRIPT;
|
|
|
|
else if (file->flags & SOUNDFILE)
|
|
|
|
return ICON_FILE_SOUND;
|
|
|
|
else if (file->flags & FTFONTFILE)
|
|
|
|
return ICON_FILE_FONT;
|
2009-12-10 14:26:06 +00:00
|
|
|
else if (file->flags & BTXFILE)
|
|
|
|
return ICON_FILE_BLANK;
|
2010-03-29 08:33:35 +00:00
|
|
|
else if (file->flags & COLLADAFILE)
|
|
|
|
return ICON_FILE_BLANK;
|
2009-03-09 08:31:45 +00:00
|
|
|
else
|
|
|
|
return ICON_FILE_BLANK;
|
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
static void file_draw_icon(uiBlock *block, char *path, int sx, int sy, int icon, int width, int height)
|
2009-03-09 08:31:45 +00:00
|
|
|
{
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
uiBut *but;
|
2011-04-10 09:37:04 +00:00
|
|
|
int x,y;
|
2011-01-12 03:41:12 +00:00
|
|
|
/*float alpha=1.0f;*/
|
2009-03-09 08:31:45 +00:00
|
|
|
|
2011-04-10 09:37:04 +00:00
|
|
|
x = sx;
|
|
|
|
y = sy-height;
|
2009-03-09 08:31:45 +00:00
|
|
|
|
2011-01-12 03:41:12 +00:00
|
|
|
/*if (icon == ICON_FILE_BLANK) alpha = 0.375f;*/
|
2011-04-10 09:37:04 +00:00
|
|
|
|
|
|
|
but= uiDefIconBut(block, LABEL, 0, icon, x, y, width, height, NULL, 0.0f, 0.0f, 0.0f, 0.0f, "");
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
uiButSetDragPath(but, path);
|
2009-03-09 08:31:45 +00:00
|
|
|
}
|
|
|
|
|
2009-05-14 18:08:14 +00:00
|
|
|
|
2010-11-14 10:48:36 +00:00
|
|
|
static void file_draw_string(int sx, int sy, const char* string, float width, int height, short align)
|
2009-01-06 14:42:54 +00:00
|
|
|
{
|
2011-07-16 18:28:24 +00:00
|
|
|
uiStyle *style= UI_GetStyle();
|
2010-11-14 10:48:36 +00:00
|
|
|
uiFontStyle fs = style->widgetlabel;
|
2010-12-15 15:56:06 +00:00
|
|
|
rcti rect;
|
|
|
|
char fname[FILE_MAXFILE];
|
2009-01-06 14:42:54 +00:00
|
|
|
|
2010-11-14 10:48:36 +00:00
|
|
|
fs.align = align;
|
BugFix:
[#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders
Blenfont was not thread safe, that is why one thread can change
the font properties (size, dpi, color, etc) at the same time
that the stamp draw on the image, and then the problem.
To make blenfont thread safe I have to change two important things:
1) Every BLF_* function take one argument, the font id.
2) We have two new function to make font "thread safe":
BLF_load_unique
BLF_load_mem_unique
This two function are for case like stamp, that need and own font
that don't share the glyph cache, so can draw without problem
in a different thread.
Why the BLF_*_unique function ?
Because blenfont keep only one copy of a font and keep a list of
"glyph cache". Every glyph cache have size and dpi, so if two
different thread access the same font at the same time, they can
change value and finish with something like the stamp problem.
Why don't remove the glyph cache ?
Because if we do that, we finish with a font object for every size
and dpi, and the stamp is really a special case that happen in
the rendering process, so I really thing is better keep the
glyph cache and make this two new function to handle this
special case.
(When I say "font object" I mean have the same freetype font multiple
times just to have differents size and dpi)
As Matt point we still can have one case that two thread access
the BLF_*_unique function at the same time, but I am looking to
fix this with some class of thread lock.
For now I test and work fine, so if some one found problem, please
let me know.
Campbell I have to change the python api (python/generic/blf_api.c)
to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
BLI_strncpy(fname,string, FILE_MAXFILE);
|
2011-03-27 17:22:04 +00:00
|
|
|
file_shorten_string(fname, width + 1.0f, 0);
|
2011-01-17 20:10:18 +00:00
|
|
|
|
2010-12-15 15:56:06 +00:00
|
|
|
/* no text clipping needed, uiStyleFontDraw does it but is a bit too strict (for buttons it works) */
|
2010-11-14 10:48:36 +00:00
|
|
|
rect.xmin = sx;
|
2011-04-10 09:37:04 +00:00
|
|
|
rect.xmax = (int)(sx + ceil(width+4.0f));
|
2010-11-14 10:48:36 +00:00
|
|
|
rect.ymin = sy - height;
|
|
|
|
rect.ymax = sy;
|
|
|
|
|
|
|
|
uiStyleFontDraw(&fs, &rect, fname);
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void file_calc_previews(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-07-28 16:46:14 +00:00
|
|
|
SpaceFile *sfile= CTX_wm_space_file(C);
|
2009-01-06 14:42:54 +00:00
|
|
|
View2D *v2d= &ar->v2d;
|
2009-03-08 13:14:12 +00:00
|
|
|
|
|
|
|
ED_fileselect_init_layout(sfile, ar);
|
2009-09-28 12:10:23 +00:00
|
|
|
/* +SCROLL_HEIGHT is bad hack to work around issue in UI_view2d_totRect_set */
|
|
|
|
UI_view2d_totRect_set(v2d, sfile->layout->width, sfile->layout->height+V2D_SCROLL_HEIGHT);
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
static void file_draw_preview(uiBlock *block, struct direntry *file, int sx, int sy, ImBuf *imb, FileLayout *layout, short dropshadow)
|
2009-01-06 14:42:54 +00:00
|
|
|
{
|
2009-08-20 18:39:25 +00:00
|
|
|
if (imb) {
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
uiBut *but;
|
|
|
|
float fx, fy;
|
|
|
|
float dx, dy;
|
|
|
|
int xco, yco;
|
|
|
|
float scaledx, scaledy;
|
|
|
|
float scale;
|
|
|
|
int ex, ey;
|
|
|
|
|
|
|
|
if ( (imb->x > layout->prv_w) || (imb->y > layout->prv_h) ) {
|
|
|
|
if (imb->x > imb->y) {
|
|
|
|
scaledx = (float)layout->prv_w;
|
|
|
|
scaledy = ( (float)imb->y/(float)imb->x )*layout->prv_w;
|
|
|
|
scale = scaledx/imb->x;
|
2009-05-14 18:08:14 +00:00
|
|
|
}
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
else {
|
|
|
|
scaledy = (float)layout->prv_h;
|
|
|
|
scaledx = ( (float)imb->x/(float)imb->y )*layout->prv_h;
|
|
|
|
scale = scaledy/imb->y;
|
2009-03-09 08:31:45 +00:00
|
|
|
}
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
} else {
|
|
|
|
scaledx = (float)imb->x;
|
|
|
|
scaledy = (float)imb->y;
|
|
|
|
scale = 1.0;
|
|
|
|
}
|
|
|
|
ex = (int)scaledx;
|
|
|
|
ey = (int)scaledy;
|
|
|
|
fx = ((float)layout->prv_w - (float)ex)/2.0f;
|
|
|
|
fy = ((float)layout->prv_h - (float)ey)/2.0f;
|
|
|
|
dx = (fx + 0.5f + layout->prv_border_x);
|
|
|
|
dy = (fy + 0.5f - layout->prv_border_y);
|
2011-04-10 09:37:04 +00:00
|
|
|
xco = sx + (int)dx;
|
|
|
|
yco = sy - layout->prv_h + (int)dy;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
|
|
|
|
|
|
|
|
/* shadow */
|
|
|
|
if (dropshadow)
|
2011-04-10 09:37:04 +00:00
|
|
|
uiDrawBoxShadow(220, (float)xco, (float)yco, (float)(xco + ex), (float)(yco + ey));
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
glEnable(GL_BLEND);
|
|
|
|
|
|
|
|
/* the image */
|
|
|
|
glColor4f(1.0, 1.0, 1.0, 1.0);
|
2011-04-10 09:37:04 +00:00
|
|
|
glaDrawPixelsTexScaled((float)xco, (float)yco, imb->x, imb->y, GL_UNSIGNED_BYTE, imb->rect, scale, scale);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
/* border */
|
|
|
|
if (dropshadow) {
|
|
|
|
glColor4f(0.0f, 0.0f, 0.0f, 0.4f);
|
2011-04-10 09:37:04 +00:00
|
|
|
fdrawbox((float)xco, (float)yco, (float)(xco + ex), (float)(yco + ey));
|
2009-03-08 13:14:12 +00:00
|
|
|
}
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
/* dragregion */
|
|
|
|
but= uiDefBut(block, LABEL, 0, "", xco, yco, ex, ey, NULL, 0.0, 0.0, 0, 0, "");
|
|
|
|
uiButSetDragImage(but, file->path, get_file_icon(file), imb, scale);
|
|
|
|
|
|
|
|
glDisable(GL_BLEND);
|
2011-03-05 10:29:10 +00:00
|
|
|
imb = NULL;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
}
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
2010-10-16 08:03:28 +00:00
|
|
|
static void renamebutton_cb(bContext *C, void *UNUSED(arg1), char *oldname)
|
2009-07-26 18:52:27 +00:00
|
|
|
{
|
|
|
|
char newname[FILE_MAX+12];
|
|
|
|
char orgname[FILE_MAX+12];
|
|
|
|
char filename[FILE_MAX+12];
|
|
|
|
SpaceFile *sfile= (SpaceFile*)CTX_wm_space_data(C);
|
2009-07-28 18:07:00 +00:00
|
|
|
ARegion* ar = CTX_wm_region(C);
|
|
|
|
|
2010-10-18 06:41:16 +00:00
|
|
|
BLI_make_file_string(G.main->name, orgname, sfile->params->dir, oldname);
|
2010-08-12 00:14:32 +00:00
|
|
|
BLI_strncpy(filename, sfile->params->renameedit, sizeof(filename));
|
2010-10-18 06:41:16 +00:00
|
|
|
BLI_make_file_string(G.main->name, newname, sfile->params->dir, filename);
|
2009-07-26 18:52:27 +00:00
|
|
|
|
|
|
|
if( strcmp(orgname, newname) != 0 ) {
|
2009-07-28 18:07:00 +00:00
|
|
|
if (!BLI_exists(newname)) {
|
|
|
|
BLI_rename(orgname, newname);
|
|
|
|
/* to make sure we show what is on disk */
|
2010-03-10 19:30:20 +00:00
|
|
|
ED_fileselect_clear(C, sfile);
|
2009-07-28 18:07:00 +00:00
|
|
|
}
|
2010-08-12 00:14:32 +00:00
|
|
|
|
2009-07-28 18:07:00 +00:00
|
|
|
ED_region_tag_redraw(ar);
|
2009-07-26 18:52:27 +00:00
|
|
|
}
|
|
|
|
}
|
2009-01-06 14:42:54 +00:00
|
|
|
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
static void draw_background(FileLayout *layout, View2D *v2d)
|
|
|
|
{
|
|
|
|
int i;
|
2009-09-28 12:10:23 +00:00
|
|
|
int sy;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
/* alternating flat shade background */
|
|
|
|
for (i=0; (i <= layout->rows); i+=2)
|
|
|
|
{
|
2011-04-10 09:37:04 +00:00
|
|
|
sy = (int)v2d->cur.ymax - i*(layout->tile_h+2*layout->tile_border_y) - layout->tile_border_y;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
UI_ThemeColorShade(TH_BACK, -7);
|
2011-04-10 09:37:04 +00:00
|
|
|
glRectf(v2d->cur.xmin, (float)sy, v2d->cur.xmax, (float)(sy+layout->tile_h+2*layout->tile_border_y));
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void draw_dividers(FileLayout *layout, View2D *v2d)
|
|
|
|
{
|
2009-09-28 12:10:23 +00:00
|
|
|
int sx;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
/* vertical column dividers */
|
2011-04-10 09:37:04 +00:00
|
|
|
sx = (int)v2d->tot.xmin;
|
2009-08-20 18:39:25 +00:00
|
|
|
while (sx < v2d->cur.xmax) {
|
|
|
|
sx += (layout->tile_w+2*layout->tile_border_x);
|
|
|
|
|
|
|
|
UI_ThemeColorShade(TH_BACK, 30);
|
2011-04-10 09:37:04 +00:00
|
|
|
sdrawline(sx+1, (short)(v2d->cur.ymax - layout->tile_border_y), sx+1, (short)v2d->cur.ymin);
|
2009-08-20 18:39:25 +00:00
|
|
|
UI_ThemeColorShade(TH_BACK, -30);
|
2011-04-10 09:37:04 +00:00
|
|
|
sdrawline(sx, (short)(v2d->cur.ymax - layout->tile_border_y), sx, (short)v2d->cur.ymin);
|
2009-08-20 18:39:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
void file_draw_list(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-07-28 16:46:14 +00:00
|
|
|
SpaceFile *sfile= CTX_wm_space_file(C);
|
2009-01-08 18:47:16 +00:00
|
|
|
FileSelectParams* params = ED_fileselect_get_params(sfile);
|
2009-03-08 13:14:12 +00:00
|
|
|
FileLayout* layout= ED_fileselect_get_layout(sfile, ar);
|
|
|
|
View2D *v2d= &ar->v2d;
|
2009-01-06 19:22:29 +00:00
|
|
|
struct FileList* files = sfile->files;
|
2009-01-06 14:42:54 +00:00
|
|
|
struct direntry *file;
|
2009-08-20 18:39:25 +00:00
|
|
|
ImBuf *imb;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
uiBlock *block = uiBeginBlock(C, ar, "FileNames", UI_EMBOSS);
|
2009-01-06 14:42:54 +00:00
|
|
|
int numfiles;
|
2009-07-26 12:40:44 +00:00
|
|
|
int numfiles_layout;
|
2009-09-28 12:10:23 +00:00
|
|
|
int sx, sy;
|
2009-01-06 14:42:54 +00:00
|
|
|
int offset;
|
2010-11-14 10:48:36 +00:00
|
|
|
int textwidth, textheight;
|
2009-01-06 14:42:54 +00:00
|
|
|
int i;
|
2009-08-20 18:39:25 +00:00
|
|
|
short is_icon;
|
2010-11-14 10:48:36 +00:00
|
|
|
short align;
|
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
|
|
|
|
numfiles = filelist_numfiles(files);
|
2009-06-04 20:07:06 +00:00
|
|
|
|
2009-08-20 18:39:25 +00:00
|
|
|
if (params->display != FILE_IMGDISPLAY) {
|
2009-05-14 18:08:14 +00:00
|
|
|
|
2009-08-20 18:39:25 +00:00
|
|
|
draw_background(layout, v2d);
|
2009-03-09 08:31:45 +00:00
|
|
|
|
2009-08-20 18:39:25 +00:00
|
|
|
draw_dividers(layout, v2d);
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
|
|
|
|
2011-04-10 09:37:04 +00:00
|
|
|
offset = ED_fileselect_layout_offset(layout, (int)ar->v2d.cur.xmin, (int)-ar->v2d.cur.ymax);
|
2009-09-28 12:10:23 +00:00
|
|
|
if (offset<0) offset=0;
|
|
|
|
|
2009-07-26 12:40:44 +00:00
|
|
|
numfiles_layout = ED_fileselect_layout_numfiles(layout, ar);
|
2009-03-08 13:14:12 +00:00
|
|
|
|
2010-05-08 21:02:22 +00:00
|
|
|
/* adjust, so the next row is already drawn when scrolling */
|
|
|
|
if (layout->flag & FILE_LAYOUT_HOR) {
|
|
|
|
numfiles_layout += layout->rows;
|
|
|
|
} else {
|
|
|
|
numfiles_layout += layout->columns;
|
|
|
|
}
|
|
|
|
|
2011-04-10 09:37:04 +00:00
|
|
|
textwidth =( FILE_IMGDISPLAY == params->display) ? layout->tile_w : (int)layout->column_widths[COLUMN_NAME];
|
|
|
|
textheight = (int)(layout->textheight*3.0/2.0 + 0.5);
|
2010-11-14 10:48:36 +00:00
|
|
|
|
|
|
|
align = ( FILE_IMGDISPLAY == params->display) ? UI_STYLE_TEXT_CENTER : UI_STYLE_TEXT_LEFT;
|
|
|
|
|
2009-07-26 12:40:44 +00:00
|
|
|
for (i=offset; (i < numfiles) && (i<offset+numfiles_layout); ++i)
|
2009-01-06 14:42:54 +00:00
|
|
|
{
|
2009-03-08 13:14:12 +00:00
|
|
|
ED_fileselect_layout_tilepos(layout, i, &sx, &sy);
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)(v2d->tot.xmin+2.0f);
|
|
|
|
sy = (int)(v2d->tot.ymax - sy);
|
2009-01-06 14:42:54 +00:00
|
|
|
|
|
|
|
file = filelist_file(files, i);
|
2009-07-26 18:52:27 +00:00
|
|
|
|
2010-02-08 22:44:55 +00:00
|
|
|
UI_ThemeColor4(TH_TEXT);
|
|
|
|
|
|
|
|
|
2011-03-20 11:16:59 +00:00
|
|
|
if (!(file->selflag & EDITING_FILE)) {
|
|
|
|
if ((params->active_file == i) || (file->selflag & HILITED_FILE) || (file->selflag & SELECTED_FILE) ) {
|
|
|
|
int colorid = (file->selflag & SELECTED_FILE) ? TH_HILITE : TH_BACK;
|
|
|
|
int shade = (params->active_file == i) || (file->selflag & HILITED_FILE) ? 20 : 0;
|
2011-03-20 00:34:08 +00:00
|
|
|
draw_tile(sx, sy-1, layout->tile_w+4, sfile->layout->tile_h+layout->tile_border_y, colorid, shade);
|
|
|
|
}
|
2009-07-26 18:52:27 +00:00
|
|
|
}
|
2011-09-11 06:41:09 +00:00
|
|
|
uiSetRoundBox(UI_CNR_NONE);
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
if ( FILE_IMGDISPLAY == params->display ) {
|
|
|
|
is_icon = 0;
|
|
|
|
imb = filelist_getimage(files, i);
|
|
|
|
if (!imb) {
|
|
|
|
imb = filelist_geticon(files,i);
|
|
|
|
is_icon = 1;
|
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
file_draw_preview(block, file, sx, sy, imb, layout, !is_icon && (file->flags & IMAGEFILE));
|
2009-08-20 18:39:25 +00:00
|
|
|
} else {
|
2011-09-25 12:33:51 +00:00
|
|
|
file_draw_icon(block, file->path, sx, sy-(UI_UNIT_Y / 6), get_file_icon(file), ICON_DEFAULT_WIDTH_SCALE, ICON_DEFAULT_HEIGHT_SCALE);
|
2011-06-05 14:00:06 +00:00
|
|
|
sx += ICON_DEFAULT_WIDTH_SCALE + 4;
|
2009-08-20 18:39:25 +00:00
|
|
|
}
|
|
|
|
|
2009-03-10 08:54:35 +00:00
|
|
|
UI_ThemeColor4(TH_TEXT);
|
2010-11-14 10:48:36 +00:00
|
|
|
|
2011-03-20 11:16:59 +00:00
|
|
|
if (file->selflag & EDITING_FILE) {
|
2010-11-14 10:48:36 +00:00
|
|
|
uiBut *but = uiDefBut(block, TEX, 1, "", sx , sy-layout->tile_h-3,
|
|
|
|
textwidth, textheight, sfile->params->renameedit, 1.0f, (float)sizeof(sfile->params->renameedit),0,0,"");
|
|
|
|
uiButSetRenameFunc(but, renamebutton_cb, file);
|
|
|
|
uiButSetFlag(but, UI_BUT_NO_UTF8); /* allow non utf8 names */
|
|
|
|
if ( 0 == uiButActiveOnly(C, block, but)) {
|
2011-03-20 11:16:59 +00:00
|
|
|
file->selflag &= ~EDITING_FILE;
|
2010-11-14 10:48:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-20 11:16:59 +00:00
|
|
|
if (!(file->selflag & EDITING_FILE)) {
|
2010-11-14 10:48:36 +00:00
|
|
|
int tpos = (FILE_IMGDISPLAY == params->display) ? sy - layout->tile_h + layout->textheight : sy;
|
2011-04-10 09:37:04 +00:00
|
|
|
file_draw_string(sx+1, tpos, file->relname, (float)textwidth, textheight, align);
|
2009-07-26 18:52:27 +00:00
|
|
|
}
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
if (params->display == FILE_SHORTDISPLAY) {
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_NAME] + 12;
|
2009-03-14 18:15:28 +00:00
|
|
|
if (!(file->type & S_IFDIR)) {
|
2010-11-14 10:48:36 +00:00
|
|
|
file_draw_string(sx, sy, file->size, layout->column_widths[COLUMN_SIZE], layout->tile_h, align);
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_SIZE] + 12;
|
2009-03-14 18:15:28 +00:00
|
|
|
}
|
2009-08-20 18:39:25 +00:00
|
|
|
} else if (params->display == FILE_LONGDISPLAY) {
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_NAME] + 12;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
|
|
|
#ifndef WIN32
|
2009-03-08 13:14:12 +00:00
|
|
|
/* rwx rwx rwx */
|
2010-11-14 11:59:42 +00:00
|
|
|
file_draw_string(sx, sy, file->mode1, layout->column_widths[COLUMN_MODE1], layout->tile_h, align);
|
2010-11-14 10:48:36 +00:00
|
|
|
sx += layout->column_widths[COLUMN_MODE1] + 12;
|
2009-03-09 21:17:19 +00:00
|
|
|
|
2010-11-14 11:59:42 +00:00
|
|
|
file_draw_string(sx, sy, file->mode2, layout->column_widths[COLUMN_MODE2], layout->tile_h, align);
|
2010-11-14 10:48:36 +00:00
|
|
|
sx += layout->column_widths[COLUMN_MODE2] + 12;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
2010-11-14 11:59:42 +00:00
|
|
|
file_draw_string(sx, sy, file->mode3, layout->column_widths[COLUMN_MODE3], layout->tile_h, align);
|
2010-11-14 10:48:36 +00:00
|
|
|
sx += layout->column_widths[COLUMN_MODE3] + 12;
|
2009-08-20 18:39:25 +00:00
|
|
|
|
2010-11-14 11:59:42 +00:00
|
|
|
file_draw_string(sx, sy, file->owner, layout->column_widths[COLUMN_OWNER] , layout->tile_h, align);
|
2010-11-14 10:48:36 +00:00
|
|
|
sx += layout->column_widths[COLUMN_OWNER] + 12;
|
2009-03-08 13:14:12 +00:00
|
|
|
#endif
|
2009-03-09 21:17:19 +00:00
|
|
|
|
2010-11-14 10:48:36 +00:00
|
|
|
file_draw_string(sx, sy, file->date, layout->column_widths[COLUMN_DATE], layout->tile_h, align);
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_DATE] + 12;
|
2009-03-08 13:14:12 +00:00
|
|
|
|
2010-11-14 10:48:36 +00:00
|
|
|
file_draw_string(sx, sy, file->time, layout->column_widths[COLUMN_TIME] , layout->tile_h, align);
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_TIME] + 12;
|
2009-03-14 18:15:28 +00:00
|
|
|
|
2009-03-14 05:21:57 +00:00
|
|
|
if (!(file->type & S_IFDIR)) {
|
2010-11-14 10:48:36 +00:00
|
|
|
file_draw_string(sx, sy, file->size, layout->column_widths[COLUMN_SIZE], layout->tile_h, align);
|
2011-04-10 09:37:04 +00:00
|
|
|
sx += (int)layout->column_widths[COLUMN_SIZE] + 12;
|
2009-03-14 05:21:57 +00:00
|
|
|
}
|
2009-03-08 13:14:12 +00:00
|
|
|
}
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|
2009-08-20 18:39:25 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
uiEndBlock(C, block);
|
|
|
|
uiDrawBlock(C, block);
|
|
|
|
|
2009-01-06 14:42:54 +00:00
|
|
|
}
|