2008-01-07 18:03:41 +00:00
|
|
|
/**
|
|
|
|
|
* $Id: resources.c 12755 2007-12-02 05:50:38Z aligorith $
|
|
|
|
|
*
|
|
|
|
|
* ***** BEGIN GPL/BL DUAL 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. The Blender
|
|
|
|
|
* Foundation also sells licenses for use in proprietary software under
|
|
|
|
|
* the Blender License. See http://www.blender.org/BL/ for information
|
|
|
|
|
* about this.
|
|
|
|
|
*
|
|
|
|
|
* 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,
|
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
|
*
|
|
|
|
|
* Contributor(s): none yet.
|
|
|
|
|
*
|
|
|
|
|
* ***** END GPL/BL DUAL LICENSE BLOCK *****
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <math.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
|
#include <config.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
|
|
|
|
|
#include "DNA_curve_types.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
#include "DNA_listBase.h"
|
|
|
|
|
#include "DNA_userdef_types.h"
|
|
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
|
#include "DNA_space_types.h"
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
#include "IMB_imbuf.h"
|
|
|
|
|
#include "IMB_imbuf_types.h"
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
#include "BKE_DerivedMesh.h"
|
|
|
|
|
#include "BKE_global.h"
|
|
|
|
|
#include "BKE_main.h"
|
|
|
|
|
#include "BKE_texture.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
#include "BKE_utildefines.h"
|
|
|
|
|
|
|
|
|
|
#include "BIF_gl.h"
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
#include "UI_interface.h"
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
#include "UI_resources.h"
|
2008-12-03 17:36:30 +00:00
|
|
|
#include "UI_interface_icons.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
#include "interface_intern.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
/* global for themes */
|
|
|
|
|
typedef void (*VectorDrawFunc)(int x, int y, int w, int h, float alpha);
|
|
|
|
|
|
|
|
|
|
static bTheme *theme_active=NULL;
|
|
|
|
|
static int theme_spacetype= SPACE_VIEW3D;
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
static int theme_regionid= RGN_TYPE_WINDOW;
|
2008-01-07 18:03:41 +00:00
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void ui_resources_init(void)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
2009-06-15 20:28:49 +00:00
|
|
|
UI_icons_init(BIFICONID_LAST);
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void ui_resources_free(void)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
2008-11-25 19:23:54 +00:00
|
|
|
UI_icons_free();
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ******************************************************** */
|
|
|
|
|
/* THEMES */
|
|
|
|
|
/* ******************************************************** */
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
char *UI_ThemeGetColorPtr(bTheme *btheme, int spacetype, int colorid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
ThemeSpace *ts= NULL;
|
|
|
|
|
static char error[4]={240, 0, 240, 255};
|
|
|
|
|
static char alert[4]={240, 60, 60, 255};
|
|
|
|
|
static char headerdesel[4]={0,0,0,255};
|
|
|
|
|
|
|
|
|
|
char *cp= error;
|
|
|
|
|
|
|
|
|
|
if(btheme) {
|
|
|
|
|
|
|
|
|
|
// first check for ui buttons theme
|
|
|
|
|
if(colorid < TH_THEMEUI) {
|
|
|
|
|
|
|
|
|
|
switch(colorid) {
|
|
|
|
|
|
|
|
|
|
case TH_REDALERT:
|
|
|
|
|
cp= alert; break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
|
|
|
|
|
switch(spacetype) {
|
|
|
|
|
case SPACE_BUTS:
|
|
|
|
|
ts= &btheme->tbuts;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_VIEW3D:
|
|
|
|
|
ts= &btheme->tv3d;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_IPO:
|
|
|
|
|
ts= &btheme->tipo;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_FILE:
|
|
|
|
|
ts= &btheme->tfile;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_NLA:
|
|
|
|
|
ts= &btheme->tnla;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_ACTION:
|
|
|
|
|
ts= &btheme->tact;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_SEQ:
|
|
|
|
|
ts= &btheme->tseq;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_IMAGE:
|
|
|
|
|
ts= &btheme->tima;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_IMASEL:
|
|
|
|
|
ts= &btheme->timasel;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_TEXT:
|
|
|
|
|
ts= &btheme->text;
|
|
|
|
|
break;
|
2009-03-26 14:05:33 +00:00
|
|
|
case SPACE_OUTLINER:
|
2008-01-07 18:03:41 +00:00
|
|
|
ts= &btheme->toops;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_SOUND:
|
|
|
|
|
ts= &btheme->tsnd;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_INFO:
|
|
|
|
|
ts= &btheme->tinfo;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_TIME:
|
|
|
|
|
ts= &btheme->ttime;
|
|
|
|
|
break;
|
|
|
|
|
case SPACE_NODE:
|
|
|
|
|
ts= &btheme->tnode;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
ts= &btheme->tv3d;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch(colorid) {
|
|
|
|
|
case TH_BACK:
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
if(theme_regionid==RGN_TYPE_WINDOW)
|
|
|
|
|
cp= ts->back;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_CHANNELS)
|
|
|
|
|
cp= ts->list;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_HEADER)
|
|
|
|
|
cp= ts->header;
|
|
|
|
|
else
|
|
|
|
|
cp= ts->button;
|
|
|
|
|
break;
|
2008-01-07 18:03:41 +00:00
|
|
|
case TH_TEXT:
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
if(theme_regionid==RGN_TYPE_WINDOW)
|
|
|
|
|
cp= ts->text;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_CHANNELS)
|
|
|
|
|
cp= ts->list_text;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_HEADER)
|
|
|
|
|
cp= ts->header_text;
|
|
|
|
|
else
|
|
|
|
|
cp= ts->button_text;
|
|
|
|
|
break;
|
2008-01-07 18:03:41 +00:00
|
|
|
case TH_TEXT_HI:
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
if(theme_regionid==RGN_TYPE_WINDOW)
|
|
|
|
|
cp= ts->text_hi;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_CHANNELS)
|
|
|
|
|
cp= ts->list_text_hi;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_HEADER)
|
|
|
|
|
cp= ts->header_text_hi;
|
|
|
|
|
else
|
|
|
|
|
cp= ts->button_text_hi;
|
|
|
|
|
break;
|
|
|
|
|
case TH_TITLE:
|
|
|
|
|
if(theme_regionid==RGN_TYPE_WINDOW)
|
|
|
|
|
cp= ts->title;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_CHANNELS)
|
|
|
|
|
cp= ts->list_title;
|
|
|
|
|
else if(theme_regionid==RGN_TYPE_HEADER)
|
|
|
|
|
cp= ts->header_title;
|
|
|
|
|
else
|
|
|
|
|
cp= ts->button_title;
|
|
|
|
|
break;
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
case TH_HEADER:
|
|
|
|
|
cp= ts->header; break;
|
|
|
|
|
case TH_HEADERDESEL:
|
|
|
|
|
/* we calculate a dynamic builtin header deselect color, also for pulldowns... */
|
|
|
|
|
cp= ts->header;
|
|
|
|
|
headerdesel[0]= cp[0]>10?cp[0]-10:0;
|
|
|
|
|
headerdesel[1]= cp[1]>10?cp[1]-10:0;
|
|
|
|
|
headerdesel[2]= cp[2]>10?cp[2]-10:0;
|
|
|
|
|
cp= headerdesel;
|
|
|
|
|
break;
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
case TH_HEADER_TEXT:
|
|
|
|
|
cp= ts->header_text; break;
|
|
|
|
|
case TH_HEADER_TEXT_HI:
|
|
|
|
|
cp= ts->header_text_hi; break;
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
case TH_PANEL:
|
|
|
|
|
cp= ts->panel; break;
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
case TH_PANEL_TEXT:
|
|
|
|
|
cp= ts->panel_text; break;
|
|
|
|
|
case TH_PANEL_TEXT_HI:
|
|
|
|
|
cp= ts->panel_text_hi; break;
|
|
|
|
|
|
|
|
|
|
case TH_BUTBACK:
|
|
|
|
|
cp= ts->button; break;
|
|
|
|
|
case TH_BUTBACK_TEXT:
|
|
|
|
|
cp= ts->button_text; break;
|
|
|
|
|
case TH_BUTBACK_TEXT_HI:
|
|
|
|
|
cp= ts->button_text_hi; break;
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
case TH_SHADE1:
|
|
|
|
|
cp= ts->shade1; break;
|
|
|
|
|
case TH_SHADE2:
|
|
|
|
|
cp= ts->shade2; break;
|
|
|
|
|
case TH_HILITE:
|
|
|
|
|
cp= ts->hilite; break;
|
|
|
|
|
|
|
|
|
|
case TH_GRID:
|
|
|
|
|
cp= ts->grid; break;
|
|
|
|
|
case TH_WIRE:
|
|
|
|
|
cp= ts->wire; break;
|
|
|
|
|
case TH_LAMP:
|
|
|
|
|
cp= ts->lamp; break;
|
|
|
|
|
case TH_SELECT:
|
|
|
|
|
cp= ts->select; break;
|
|
|
|
|
case TH_ACTIVE:
|
|
|
|
|
cp= ts->active; break;
|
|
|
|
|
case TH_GROUP:
|
|
|
|
|
cp= ts->group; break;
|
|
|
|
|
case TH_GROUP_ACTIVE:
|
|
|
|
|
cp= ts->group_active; break;
|
|
|
|
|
case TH_TRANSFORM:
|
|
|
|
|
cp= ts->transform; break;
|
|
|
|
|
case TH_VERTEX:
|
|
|
|
|
cp= ts->vertex; break;
|
|
|
|
|
case TH_VERTEX_SELECT:
|
|
|
|
|
cp= ts->vertex_select; break;
|
|
|
|
|
case TH_VERTEX_SIZE:
|
|
|
|
|
cp= &ts->vertex_size; break;
|
|
|
|
|
case TH_EDGE:
|
|
|
|
|
cp= ts->edge; break;
|
|
|
|
|
case TH_EDGE_SELECT:
|
|
|
|
|
cp= ts->edge_select; break;
|
|
|
|
|
case TH_EDGE_SEAM:
|
|
|
|
|
cp= ts->edge_seam; break;
|
|
|
|
|
case TH_EDGE_SHARP:
|
|
|
|
|
cp= ts->edge_sharp; break;
|
|
|
|
|
case TH_EDITMESH_ACTIVE:
|
|
|
|
|
cp= ts->editmesh_active; break;
|
|
|
|
|
case TH_EDGE_FACESEL:
|
|
|
|
|
cp= ts->edge_facesel; break;
|
|
|
|
|
case TH_FACE:
|
|
|
|
|
cp= ts->face; break;
|
|
|
|
|
case TH_FACE_SELECT:
|
|
|
|
|
cp= ts->face_select; break;
|
|
|
|
|
case TH_FACE_DOT:
|
|
|
|
|
cp= ts->face_dot; break;
|
|
|
|
|
case TH_FACEDOT_SIZE:
|
|
|
|
|
cp= &ts->facedot_size; break;
|
|
|
|
|
case TH_NORMAL:
|
|
|
|
|
cp= ts->normal; break;
|
|
|
|
|
case TH_BONE_SOLID:
|
|
|
|
|
cp= ts->bone_solid; break;
|
|
|
|
|
case TH_BONE_POSE:
|
|
|
|
|
cp= ts->bone_pose; break;
|
|
|
|
|
case TH_STRIP:
|
|
|
|
|
cp= ts->strip; break;
|
|
|
|
|
case TH_STRIP_SELECT:
|
|
|
|
|
cp= ts->strip_select; break;
|
|
|
|
|
case TH_CFRAME:
|
|
|
|
|
cp= ts->cframe; break;
|
|
|
|
|
|
|
|
|
|
case TH_SYNTAX_B:
|
|
|
|
|
cp= ts->syntaxb; break;
|
|
|
|
|
case TH_SYNTAX_V:
|
|
|
|
|
cp= ts->syntaxv; break;
|
|
|
|
|
case TH_SYNTAX_C:
|
|
|
|
|
cp= ts->syntaxc; break;
|
|
|
|
|
case TH_SYNTAX_L:
|
|
|
|
|
cp= ts->syntaxl; break;
|
|
|
|
|
case TH_SYNTAX_N:
|
|
|
|
|
cp= ts->syntaxn; break;
|
|
|
|
|
|
|
|
|
|
case TH_NODE:
|
|
|
|
|
cp= ts->syntaxl; break;
|
|
|
|
|
case TH_NODE_IN_OUT:
|
|
|
|
|
cp= ts->syntaxn; break;
|
|
|
|
|
case TH_NODE_OPERATOR:
|
|
|
|
|
cp= ts->syntaxb; break;
|
|
|
|
|
case TH_NODE_CONVERTOR:
|
|
|
|
|
cp= ts->syntaxv; break;
|
|
|
|
|
case TH_NODE_GROUP:
|
|
|
|
|
cp= ts->syntaxc; break;
|
|
|
|
|
|
|
|
|
|
case TH_SEQ_MOVIE:
|
|
|
|
|
cp= ts->movie; break;
|
|
|
|
|
case TH_SEQ_IMAGE:
|
|
|
|
|
cp= ts->image; break;
|
|
|
|
|
case TH_SEQ_SCENE:
|
|
|
|
|
cp= ts->scene; break;
|
|
|
|
|
case TH_SEQ_AUDIO:
|
|
|
|
|
cp= ts->audio; break;
|
|
|
|
|
case TH_SEQ_EFFECT:
|
|
|
|
|
cp= ts->effect; break;
|
|
|
|
|
case TH_SEQ_PLUGIN:
|
|
|
|
|
cp= ts->plugin; break;
|
|
|
|
|
case TH_SEQ_TRANSITION:
|
|
|
|
|
cp= ts->transition; break;
|
|
|
|
|
case TH_SEQ_META:
|
|
|
|
|
cp= ts->meta; break;
|
|
|
|
|
|
2008-12-22 09:43:54 +00:00
|
|
|
case TH_HANDLE_VERTEX:
|
|
|
|
|
cp= ts->handle_vertex;
|
|
|
|
|
break;
|
|
|
|
|
case TH_HANDLE_VERTEX_SELECT:
|
|
|
|
|
cp= ts->handle_vertex_select;
|
|
|
|
|
break;
|
|
|
|
|
case TH_HANDLE_VERTEX_SIZE:
|
|
|
|
|
cp= &ts->handle_vertex_size;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TH_DOPESHEET_CHANNELOB:
|
|
|
|
|
cp= ts->ds_channel;
|
|
|
|
|
break;
|
|
|
|
|
case TH_DOPESHEET_CHANNELSUBOB:
|
|
|
|
|
cp= ts->ds_subchannel;
|
|
|
|
|
break;
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cp;
|
|
|
|
|
}
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
#define SETCOLTEST(col, r, g, b, a) if(col[3]==0) {col[0]=r; col[1]=g; col[2]= b; col[3]= a;}
|
|
|
|
|
|
|
|
|
|
/* use this call to init new variables in themespace, if they're same for all */
|
|
|
|
|
static void ui_theme_init_new_do(ThemeSpace *ts)
|
|
|
|
|
{
|
|
|
|
|
SETCOLTEST(ts->header_text, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->header_title, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->header_text_hi, 255, 255, 255, 255);
|
|
|
|
|
|
|
|
|
|
SETCOLTEST(ts->panel_text, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->panel_title, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->panel_text_hi, 255, 255, 255, 255);
|
|
|
|
|
|
|
|
|
|
SETCOLTEST(ts->button, 145, 145, 145, 245);
|
|
|
|
|
SETCOLTEST(ts->button_title, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->button_text, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->button_text_hi, 255, 255, 255, 255);
|
|
|
|
|
|
|
|
|
|
SETCOLTEST(ts->list, 165, 165, 165, 255);
|
|
|
|
|
SETCOLTEST(ts->list_title, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->list_text, 0, 0, 0, 255);
|
|
|
|
|
SETCOLTEST(ts->list_text_hi, 255, 255, 255, 255);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ui_theme_init_new(bTheme *btheme)
|
|
|
|
|
{
|
|
|
|
|
ui_theme_init_new_do(&btheme->tbuts);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tv3d);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tfile);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tipo);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tinfo);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tsnd);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tact);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tnla);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tseq);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tima);
|
|
|
|
|
ui_theme_init_new_do(&btheme->timasel);
|
|
|
|
|
ui_theme_init_new_do(&btheme->text);
|
|
|
|
|
ui_theme_init_new_do(&btheme->toops);
|
|
|
|
|
ui_theme_init_new_do(&btheme->ttime);
|
|
|
|
|
ui_theme_init_new_do(&btheme->tnode);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
#define SETCOL(col, r, g, b, a) col[0]=r; col[1]=g; col[2]= b; col[3]= a;
|
2009-04-29 04:43:17 +00:00
|
|
|
#define SETCOLF(col, r, g, b, a) col[0]=r*255; col[1]=g*255; col[2]= b*255; col[3]= a*255;
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
/* initialize default theme, can't be edited
|
2008-01-07 18:03:41 +00:00
|
|
|
Note: when you add new colors, created & saved themes need initialized
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
use function below, init_userdef_do_versions()
|
2008-01-07 18:03:41 +00:00
|
|
|
*/
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void ui_theme_init_userdef(void)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
bTheme *btheme= U.themes.first;
|
|
|
|
|
|
|
|
|
|
/* we search for the theme with name Default */
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
if(strcmp("Default", btheme->name)==0) break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(btheme==NULL) {
|
|
|
|
|
btheme= MEM_callocN(sizeof(bTheme), "theme");
|
|
|
|
|
BLI_addtail(&U.themes, btheme);
|
|
|
|
|
strcpy(btheme->name, "Default");
|
|
|
|
|
}
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
UI_SetTheme(0, 0); // make sure the global used in this file is set
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2009-03-14 03:24:23 +00:00
|
|
|
/* UI buttons */
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
ui_widget_color_init(&btheme->tui);
|
2008-12-23 02:03:08 +00:00
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
/* common (new) variables */
|
|
|
|
|
ui_theme_init_new(btheme);
|
|
|
|
|
|
2009-01-04 00:05:40 +00:00
|
|
|
/* space view3d */
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->tv3d.back, 0.225, 0.225, 0.225, 1.0);
|
2009-01-04 00:05:40 +00:00
|
|
|
SETCOL(btheme->tv3d.text, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.text_hi, 255, 255, 255, 255);
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->tv3d.header, 0.45, 0.45, 0.45, 1.0);
|
2009-01-04 00:05:40 +00:00
|
|
|
SETCOL(btheme->tv3d.panel, 165, 165, 165, 127);
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
|
2009-01-04 00:05:40 +00:00
|
|
|
SETCOL(btheme->tv3d.shade1, 160, 160, 160, 100);
|
|
|
|
|
SETCOL(btheme->tv3d.shade2, 0x7f, 0x70, 0x70, 100);
|
2008-12-23 02:03:08 +00:00
|
|
|
|
2009-05-16 17:30:13 +00:00
|
|
|
SETCOLF(btheme->tv3d.grid, 0.251, 0.251, 0.251, 1.0);
|
2009-01-04 00:05:40 +00:00
|
|
|
SETCOL(btheme->tv3d.wire, 0x0, 0x0, 0x0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.lamp, 0, 0, 0, 40);
|
|
|
|
|
SETCOL(btheme->tv3d.select, 241, 88, 0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.active, 255, 140, 25, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.group, 16, 64, 16, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.group_active, 85, 187, 85, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.transform, 0xff, 0xff, 0xff, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.vertex, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.vertex_select, 255, 133, 0, 255);
|
|
|
|
|
btheme->tv3d.vertex_size= 3;
|
|
|
|
|
SETCOL(btheme->tv3d.edge, 0x0, 0x0, 0x0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.edge_select, 255, 160, 0, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.edge_seam, 219, 37, 18, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.edge_facesel, 75, 75, 75, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.face, 0, 0, 0, 18);
|
|
|
|
|
SETCOL(btheme->tv3d.face_select, 255, 133, 0, 60);
|
|
|
|
|
SETCOL(btheme->tv3d.normal, 0x22, 0xDD, 0xDD, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.face_dot, 255, 133, 0, 255);
|
|
|
|
|
btheme->tv3d.facedot_size= 4;
|
|
|
|
|
SETCOL(btheme->tv3d.cframe, 0x60, 0xc0, 0x40, 255);
|
2008-12-23 02:03:08 +00:00
|
|
|
|
2009-01-04 00:05:40 +00:00
|
|
|
SETCOL(btheme->tv3d.bone_solid, 200, 200, 200, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.bone_pose, 80, 200, 255, 80); // alpha 80 is not meant editable, used for wire+action draw
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/* space buttons */
|
|
|
|
|
/* to have something initialized */
|
|
|
|
|
btheme->tbuts= btheme->tv3d;
|
|
|
|
|
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->tbuts.back, 0.45, 0.45, 0.45, 1.0);
|
2009-03-14 03:24:23 +00:00
|
|
|
SETCOL(btheme->tbuts.panel, 0x82, 0x82, 0x82, 255);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2009-04-29 04:43:17 +00:00
|
|
|
/* graph editor */
|
2008-01-07 18:03:41 +00:00
|
|
|
btheme->tipo= btheme->tv3d;
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->tipo.back, 0.42, 0.42, 0.42, 1.0);
|
|
|
|
|
SETCOLF(btheme->tipo.list, 0.4, 0.4, 0.4, 1.0);
|
2008-01-07 18:03:41 +00:00
|
|
|
SETCOL(btheme->tipo.grid, 94, 94, 94, 255);
|
|
|
|
|
SETCOL(btheme->tipo.panel, 255, 255, 255, 150);
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOL(btheme->tipo.shade1, 150, 150, 150, 100); /* scrollbars */
|
2009-02-09 02:54:40 +00:00
|
|
|
SETCOL(btheme->tipo.shade2, 0x70, 0x70, 0x70, 100);
|
|
|
|
|
SETCOL(btheme->tipo.vertex, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tipo.vertex_select, 255, 133, 0, 255);
|
2008-01-07 18:03:41 +00:00
|
|
|
SETCOL(btheme->tipo.hilite, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
btheme->tipo.vertex_size= 3;
|
|
|
|
|
|
2009-02-09 02:54:40 +00:00
|
|
|
SETCOL(btheme->tipo.handle_vertex, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tipo.handle_vertex_select, 255, 133, 0, 255);
|
2008-12-22 08:13:25 +00:00
|
|
|
btheme->tipo.handle_vertex_size= 3;
|
Animato/2.5 - Graph Editor (i.e. the new 'IPO Editor')
This commit brings back the drawing code for the 'Graph Editor'. I've decided to call it this, as currently it can show either F-Curves for Animation stored in Actions, or F-Curves for Drivers.
Currently, it shows all curves, since some of the necessary filtering code (i.e. for limiting curve visibility) hasn't been put in place yet. At least this serves as good proof that we can have F-Curves from multiple sources at least.
It should be noted that the code still has to be modified to work with some of the new Animato features, such as F-Curve Modifiers (cycles are an example of one of the features that use this). Also, a nicer way to set the colours of the curves needs to be investigated.
Notes:
* Fixed a few bugs in RNA User-Preferences wrapping
* The keyframe drawing uses the new-style drawing for handles from AnimSys2. There's a minor bug that sometimes occurs, where a distorted handle gets drawn at the origin of the grid on the first run. Hints anyone?
* Removed most of the old data from SpaceIpo struct, as the new code uses that. Maybe later, the directories/files at least should get renamed.
* Removed ancient hack for NVidia/TNT drivers. It is probably no longer needed, but could be restored if someone needs it.
2009-01-26 11:33:16 +00:00
|
|
|
|
2009-02-09 02:54:40 +00:00
|
|
|
SETCOL(btheme->tipo.ds_channel, 82, 96, 110, 255);
|
|
|
|
|
SETCOL(btheme->tipo.ds_subchannel, 124, 137, 150, 255);
|
2009-02-10 03:27:33 +00:00
|
|
|
SETCOL(btheme->tipo.group, 79, 101, 73, 255);
|
|
|
|
|
SETCOL(btheme->tipo.group_active, 135, 177, 125, 255);
|
2008-12-22 08:13:25 +00:00
|
|
|
|
2009-04-29 04:43:17 +00:00
|
|
|
/* dopesheet */
|
|
|
|
|
btheme->tact= btheme->tipo;
|
2009-05-17 06:57:48 +00:00
|
|
|
SETCOL(btheme->tact.strip, 12, 10, 10, 128);
|
|
|
|
|
SETCOL(btheme->tact.strip_select, 255, 140, 0, 255);
|
2009-04-29 04:43:17 +00:00
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
/* space file */
|
|
|
|
|
/* to have something initialized */
|
|
|
|
|
btheme->tfile= btheme->tv3d;
|
2009-03-09 08:31:45 +00:00
|
|
|
SETCOL(btheme->tfile.back, 90, 90, 90, 255);
|
2009-03-10 08:54:35 +00:00
|
|
|
SETCOL(btheme->tfile.text, 250, 250, 250, 255);
|
|
|
|
|
SETCOL(btheme->tfile.text_hi, 15, 15, 15, 255);
|
2009-03-14 03:24:23 +00:00
|
|
|
SETCOL(btheme->tfile.panel, 180, 180, 180, 255); // bookmark/ui regions
|
2009-03-09 08:31:45 +00:00
|
|
|
SETCOL(btheme->tfile.active, 130, 130, 130, 255); // selected files
|
2009-03-10 08:54:35 +00:00
|
|
|
SETCOL(btheme->tfile.hilite, 255, 140, 25, 255); // selected files
|
2009-03-09 08:31:45 +00:00
|
|
|
|
2009-03-10 08:54:35 +00:00
|
|
|
SETCOL(btheme->tfile.grid, 250, 250, 250, 255);
|
|
|
|
|
SETCOL(btheme->tfile.image, 250, 250, 250, 255);
|
|
|
|
|
SETCOL(btheme->tfile.movie, 250, 250, 250, 255);
|
|
|
|
|
SETCOL(btheme->tfile.scene, 250, 250, 250, 255);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
|
2009-04-29 04:43:17 +00:00
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
/* space nla */
|
|
|
|
|
btheme->tnla= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tnla.back, 116, 116, 116, 255);
|
|
|
|
|
SETCOL(btheme->tnla.text, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tnla.text_hi, 255, 255, 255, 255);
|
|
|
|
|
SETCOL(btheme->tnla.grid, 94, 94, 94, 255);
|
|
|
|
|
SETCOL(btheme->tnla.shade1, 172, 172, 172, 255); // sliders
|
|
|
|
|
SETCOL(btheme->tnla.shade2, 84, 44, 31, 100); // bar
|
|
|
|
|
SETCOL(btheme->tnla.hilite, 17, 27, 60, 100); // bar
|
|
|
|
|
SETCOL(btheme->tnla.strip_select, 0xff, 0xff, 0xaa, 255);
|
|
|
|
|
SETCOL(btheme->tnla.strip, 0xe4, 0x9c, 0xc6, 255);
|
|
|
|
|
|
|
|
|
|
/* space seq */
|
|
|
|
|
btheme->tseq= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tseq.back, 116, 116, 116, 255);
|
|
|
|
|
SETCOL(btheme->tseq.movie, 81, 105, 135, 255);
|
|
|
|
|
SETCOL(btheme->tseq.image, 109, 88, 129, 255);
|
|
|
|
|
SETCOL(btheme->tseq.scene, 78, 152, 62, 255);
|
|
|
|
|
SETCOL(btheme->tseq.audio, 46, 143, 143, 255);
|
|
|
|
|
SETCOL(btheme->tseq.effect, 169, 84, 124, 255);
|
|
|
|
|
SETCOL(btheme->tseq.plugin, 126, 126, 80, 255);
|
|
|
|
|
SETCOL(btheme->tseq.transition, 162, 95, 111, 255);
|
|
|
|
|
SETCOL(btheme->tseq.meta, 109, 145, 131, 255);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* space image */
|
|
|
|
|
btheme->tima= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tima.back, 53, 53, 53, 255);
|
2009-02-09 02:54:40 +00:00
|
|
|
SETCOL(btheme->tima.vertex, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->tima.vertex_select, 255, 133, 0, 255);
|
|
|
|
|
btheme->tima.vertex_size= 3;
|
|
|
|
|
btheme->tima.facedot_size= 3;
|
|
|
|
|
SETCOL(btheme->tima.face, 255, 255, 255, 10);
|
|
|
|
|
SETCOL(btheme->tima.face_select, 255, 133, 0, 60);
|
2009-01-17 22:14:08 +00:00
|
|
|
SETCOL(btheme->tima.editmesh_active, 255, 255, 255, 128);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
/* space imageselect */
|
|
|
|
|
btheme->timasel= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->timasel.active, 195, 195, 195, 255); /* active tile */
|
|
|
|
|
SETCOL(btheme->timasel.grid, 94, 94, 94, 255); /* active file text */
|
|
|
|
|
SETCOL(btheme->timasel.back, 110, 110, 110, 255);
|
|
|
|
|
SETCOL(btheme->timasel.shade1, 94, 94, 94, 255); /* bar */
|
|
|
|
|
SETCOL(btheme->timasel.shade2, 172, 172, 172, 255); /* sliders */
|
|
|
|
|
SETCOL(btheme->timasel.hilite, 17, 27, 60, 100); /* selected tile */
|
|
|
|
|
SETCOL(btheme->timasel.text, 0, 0, 0, 255);
|
|
|
|
|
SETCOL(btheme->timasel.text_hi, 255, 255, 255, 255);
|
|
|
|
|
SETCOL(btheme->timasel.panel, 132, 132, 132, 255);
|
|
|
|
|
|
|
|
|
|
/* space text */
|
|
|
|
|
btheme->text= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->text.back, 153, 153, 153, 255);
|
|
|
|
|
SETCOL(btheme->text.shade1, 143, 143, 143, 255);
|
|
|
|
|
SETCOL(btheme->text.shade2, 0xc6, 0x77, 0x77, 255);
|
|
|
|
|
SETCOL(btheme->text.hilite, 255, 0, 0, 255);
|
|
|
|
|
|
|
|
|
|
/* syntax highlighting */
|
|
|
|
|
SETCOL(btheme->text.syntaxn, 0, 0, 200, 255); /* Numbers Blue*/
|
|
|
|
|
SETCOL(btheme->text.syntaxl, 100, 0, 0, 255); /* Strings red */
|
|
|
|
|
SETCOL(btheme->text.syntaxc, 0, 100, 50, 255); /* Comments greenish */
|
|
|
|
|
SETCOL(btheme->text.syntaxv, 95, 95, 0, 255); /* Special */
|
|
|
|
|
SETCOL(btheme->text.syntaxb, 128, 0, 80, 255); /* Builtin, red-purple */
|
|
|
|
|
|
|
|
|
|
/* space oops */
|
|
|
|
|
btheme->toops= btheme->tv3d;
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->toops.back, 0.45, 0.45, 0.45, 1.0);
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
/* space info */
|
|
|
|
|
btheme->tinfo= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tinfo.back, 153, 153, 153, 255);
|
|
|
|
|
|
|
|
|
|
/* space sound */
|
|
|
|
|
btheme->tsnd= btheme->tv3d;
|
2009-04-29 04:43:17 +00:00
|
|
|
SETCOLF(btheme->tsnd.back, 0.45, 0.45, 0.45, 1.0);
|
|
|
|
|
SETCOLF(btheme->tsnd.grid, 0.36, 0.36, 0.36, 1.0);
|
2008-01-07 18:03:41 +00:00
|
|
|
SETCOL(btheme->tsnd.shade1, 173, 173, 173, 255); // sliders
|
|
|
|
|
|
|
|
|
|
/* space time */
|
|
|
|
|
btheme->ttime= btheme->tsnd; // same as sound space
|
|
|
|
|
|
|
|
|
|
/* space node, re-uses syntax color storage */
|
|
|
|
|
btheme->tnode= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tnode.edge_select, 255, 255, 255, 255);
|
|
|
|
|
SETCOL(btheme->tnode.syntaxl, 150, 150, 150, 255); /* TH_NODE, backdrop */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxn, 129, 131, 144, 255); /* in/output */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxb, 127,127,127, 255); /* operator */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxv, 142, 138, 145, 255); /* generator */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxc, 120, 145, 120, 255); /* group */
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
void UI_SetTheme(int spacetype, int regionid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
if(spacetype==0) { // called for safety, when delete themes
|
2008-01-07 18:03:41 +00:00
|
|
|
theme_active= U.themes.first;
|
|
|
|
|
theme_spacetype= SPACE_VIEW3D;
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
theme_regionid= RGN_TYPE_WINDOW;
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
// later on, a local theme can be found too
|
|
|
|
|
theme_active= U.themes.first;
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
theme_spacetype= spacetype;
|
|
|
|
|
theme_regionid= regionid;
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// for space windows only
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColor(int colorid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
glColor3ub(cp[0], cp[1], cp[2]);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// plus alpha
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColor4(int colorid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
glColor4ub(cp[0], cp[1], cp[2], cp[3]);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// set the color with offset for shades
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColorShade(int colorid, int offset)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b;
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
r= offset + (int) cp[0];
|
|
|
|
|
CLAMP(r, 0, 255);
|
|
|
|
|
g= offset + (int) cp[1];
|
|
|
|
|
CLAMP(g, 0, 255);
|
|
|
|
|
b= offset + (int) cp[2];
|
|
|
|
|
CLAMP(b, 0, 255);
|
|
|
|
|
//glColor3ub(r, g, b);
|
|
|
|
|
glColor4ub(r, g, b, cp[3]);
|
|
|
|
|
}
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColorShadeAlpha(int colorid, int coloffset, int alphaoffset)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b, a;
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
r= coloffset + (int) cp[0];
|
|
|
|
|
CLAMP(r, 0, 255);
|
|
|
|
|
g= coloffset + (int) cp[1];
|
|
|
|
|
CLAMP(g, 0, 255);
|
|
|
|
|
b= coloffset + (int) cp[2];
|
|
|
|
|
CLAMP(b, 0, 255);
|
|
|
|
|
a= alphaoffset + (int) cp[3];
|
|
|
|
|
CLAMP(a, 0, 255);
|
|
|
|
|
glColor4ub(r, g, b, a);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// blend between to theme colors, and set it
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColorBlend(int colorid1, int colorid2, float fac)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b;
|
|
|
|
|
char *cp1, *cp2;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp1= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid1);
|
|
|
|
|
cp2= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid2);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
if(fac<0.0) fac=0.0; else if(fac>1.0) fac= 1.0;
|
|
|
|
|
r= floor((1.0-fac)*cp1[0] + fac*cp2[0]);
|
|
|
|
|
g= floor((1.0-fac)*cp1[1] + fac*cp2[1]);
|
|
|
|
|
b= floor((1.0-fac)*cp1[2] + fac*cp2[2]);
|
|
|
|
|
|
|
|
|
|
glColor3ub(r, g, b);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// blend between to theme colors, shade it, and set it
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ThemeColorBlendShade(int colorid1, int colorid2, float fac, int offset)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b;
|
|
|
|
|
char *cp1, *cp2;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp1= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid1);
|
|
|
|
|
cp2= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid2);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
if(fac<0.0) fac=0.0; else if(fac>1.0) fac= 1.0;
|
|
|
|
|
r= offset+floor((1.0-fac)*cp1[0] + fac*cp2[0]);
|
|
|
|
|
g= offset+floor((1.0-fac)*cp1[1] + fac*cp2[1]);
|
|
|
|
|
b= offset+floor((1.0-fac)*cp1[2] + fac*cp2[2]);
|
|
|
|
|
|
2009-01-04 07:50:41 +00:00
|
|
|
CLAMP(r, 0, 255);
|
|
|
|
|
CLAMP(g, 0, 255);
|
|
|
|
|
CLAMP(b, 0, 255);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
|
|
|
|
glColor3ub(r, g, b);
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-04 07:50:41 +00:00
|
|
|
// blend between to theme colors, shade it, and set it
|
|
|
|
|
void UI_ThemeColorBlendShadeAlpha(int colorid1, int colorid2, float fac, int offset, int alphaoffset)
|
|
|
|
|
{
|
|
|
|
|
int r, g, b, a;
|
|
|
|
|
char *cp1, *cp2;
|
|
|
|
|
|
|
|
|
|
cp1= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid1);
|
|
|
|
|
cp2= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid2);
|
|
|
|
|
|
|
|
|
|
if(fac<0.0) fac=0.0; else if(fac>1.0) fac= 1.0;
|
|
|
|
|
r= offset+floor((1.0-fac)*cp1[0] + fac*cp2[0]);
|
|
|
|
|
g= offset+floor((1.0-fac)*cp1[1] + fac*cp2[1]);
|
|
|
|
|
b= offset+floor((1.0-fac)*cp1[2] + fac*cp2[2]);
|
|
|
|
|
a= alphaoffset+floor((1.0-fac)*cp1[3] + fac*cp2[3]);
|
|
|
|
|
|
|
|
|
|
CLAMP(r, 0, 255);
|
|
|
|
|
CLAMP(g, 0, 255);
|
|
|
|
|
CLAMP(b, 0, 255);
|
|
|
|
|
CLAMP(a, 0, 255);
|
|
|
|
|
|
|
|
|
|
glColor4ub(r, g, b, a);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
// get individual values, not scaled
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
float UI_GetThemeValuef(int colorid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
return ((float)cp[0]);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// get individual values, not scaled
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
int UI_GetThemeValue(int colorid)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
return ((int) cp[0]);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// get the color, range 0.0-1.0
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_GetThemeColor3fv(int colorid, float *col)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
col[0]= ((float)cp[0])/255.0;
|
|
|
|
|
col[1]= ((float)cp[1])/255.0;
|
|
|
|
|
col[2]= ((float)cp[2])/255.0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// get the color, in char pointer
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_GetThemeColor3ubv(int colorid, char *col)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
col[0]= cp[0];
|
|
|
|
|
col[1]= cp[1];
|
|
|
|
|
col[2]= cp[2];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// get the color, in char pointer
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_GetThemeColor4ubv(int colorid, char *col)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, theme_spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
col[0]= cp[0];
|
|
|
|
|
col[1]= cp[1];
|
|
|
|
|
col[2]= cp[2];
|
|
|
|
|
col[3]= cp[3];
|
|
|
|
|
}
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_GetThemeColorType4ubv(int colorid, int spacetype, char *col)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
char *cp;
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
cp= UI_ThemeGetColorPtr(theme_active, spacetype, colorid);
|
2008-01-07 18:03:41 +00:00
|
|
|
col[0]= cp[0];
|
|
|
|
|
col[1]= cp[1];
|
|
|
|
|
col[2]= cp[2];
|
|
|
|
|
col[3]= cp[3];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// blends and shades between two char color pointers
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_ColorPtrBlendShade3ubv(char *cp1, char *cp2, float fac, int offset)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b;
|
|
|
|
|
|
|
|
|
|
if(fac<0.0) fac=0.0; else if(fac>1.0) fac= 1.0;
|
|
|
|
|
r= offset+floor((1.0-fac)*cp1[0] + fac*cp2[0]);
|
|
|
|
|
g= offset+floor((1.0-fac)*cp1[1] + fac*cp2[1]);
|
|
|
|
|
b= offset+floor((1.0-fac)*cp1[2] + fac*cp2[2]);
|
|
|
|
|
|
|
|
|
|
r= r<0?0:(r>255?255:r);
|
|
|
|
|
g= g<0?0:(g>255?255:g);
|
|
|
|
|
b= b<0?0:(b>255?255:b);
|
|
|
|
|
|
|
|
|
|
glColor3ub(r, g, b);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// get a 3 byte color, blended and shaded between two other char color pointers
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
void UI_GetColorPtrBlendShade3ubv(char *cp1, char *cp2, char *col, float fac, int offset)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
|
int r, g, b;
|
|
|
|
|
|
|
|
|
|
if(fac<0.0) fac=0.0; else if(fac>1.0) fac= 1.0;
|
|
|
|
|
r= offset+floor((1.0-fac)*cp1[0] + fac*cp2[0]);
|
|
|
|
|
g= offset+floor((1.0-fac)*cp1[1] + fac*cp2[1]);
|
|
|
|
|
b= offset+floor((1.0-fac)*cp1[2] + fac*cp2[2]);
|
|
|
|
|
|
|
|
|
|
r= r<0?0:(r>255?255:r);
|
|
|
|
|
g= g<0?0:(g>255?255:g);
|
|
|
|
|
b= b<0?0:(b>255?255:b);
|
|
|
|
|
|
|
|
|
|
col[0] = r;
|
|
|
|
|
col[1] = g;
|
|
|
|
|
col[2] = b;
|
|
|
|
|
}
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2009-04-30 11:47:35 +00:00
|
|
|
void UI_make_axis_color(char *src_col, char *dst_col, char axis)
|
|
|
|
|
{
|
|
|
|
|
switch(axis)
|
|
|
|
|
{
|
|
|
|
|
case 'x':
|
|
|
|
|
case 'X':
|
|
|
|
|
dst_col[0]= src_col[0]>219?255:src_col[0]+36;
|
|
|
|
|
dst_col[1]= src_col[1]<26?0:src_col[1]-26;
|
|
|
|
|
dst_col[2]= src_col[2]<26?0:src_col[2]-26;
|
|
|
|
|
break;
|
|
|
|
|
case 'y':
|
|
|
|
|
case 'Y':
|
|
|
|
|
dst_col[0]= src_col[0]<46?0:src_col[0]-36;
|
|
|
|
|
dst_col[1]= src_col[1]>189?255:src_col[1]+66;
|
|
|
|
|
dst_col[2]= src_col[2]<46?0:src_col[2]-36;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
dst_col[0]= src_col[0]<26?0:src_col[0]-26;
|
|
|
|
|
dst_col[1]= src_col[1]<26?0:src_col[1]-26;
|
|
|
|
|
dst_col[2]= src_col[2]>209?255:src_col[2]+46;
|
|
|
|
|
}
|
|
|
|
|
}
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
|
|
|
|
|
/* ************************************************************* */
|
|
|
|
|
|
|
|
|
|
/* patching UserDef struct and Themes */
|
|
|
|
|
void init_userdef_do_versions(void)
|
|
|
|
|
{
|
|
|
|
|
// countall();
|
|
|
|
|
|
|
|
|
|
/* the UserDef struct is not corrected with do_versions() .... ugh! */
|
|
|
|
|
if(U.wheellinescroll == 0) U.wheellinescroll = 3;
|
|
|
|
|
if(U.menuthreshold1==0) {
|
|
|
|
|
U.menuthreshold1= 5;
|
|
|
|
|
U.menuthreshold2= 2;
|
|
|
|
|
}
|
|
|
|
|
if(U.tb_leftmouse==0) {
|
|
|
|
|
U.tb_leftmouse= 5;
|
|
|
|
|
U.tb_rightmouse= 5;
|
|
|
|
|
}
|
|
|
|
|
if(U.mixbufsize==0) U.mixbufsize= 2048;
|
|
|
|
|
if (BLI_streq(U.tempdir, "/")) {
|
|
|
|
|
char *tmp= getenv("TEMP");
|
|
|
|
|
|
|
|
|
|
strcpy(U.tempdir, tmp?tmp:"/tmp/");
|
|
|
|
|
}
|
|
|
|
|
if (U.savetime <= 0) {
|
|
|
|
|
U.savetime = 1;
|
|
|
|
|
// XXX error(".B.blend is buggy, please consider removing it.\n");
|
|
|
|
|
}
|
|
|
|
|
/* transform widget settings */
|
|
|
|
|
if(U.tw_hotspot==0) {
|
|
|
|
|
U.tw_hotspot= 14;
|
|
|
|
|
U.tw_size= 20; // percentage of window size
|
|
|
|
|
U.tw_handlesize= 16; // percentage of widget radius
|
|
|
|
|
}
|
|
|
|
|
if(U.pad_rot_angle==0)
|
|
|
|
|
U.pad_rot_angle= 15;
|
|
|
|
|
|
|
|
|
|
if(U.flag & USER_CUSTOM_RANGE)
|
|
|
|
|
vDM_ColorBand_store(&U.coba_weight); /* signal for derivedmesh to use colorband */
|
|
|
|
|
|
|
|
|
|
if (G.main->versionfile <= 191) {
|
|
|
|
|
strcpy(U.plugtexdir, U.textudir);
|
|
|
|
|
strcpy(U.sounddir, "/");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* patch to set Dupli Armature */
|
|
|
|
|
if (G.main->versionfile < 220) {
|
|
|
|
|
U.dupflag |= USER_DUP_ARM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* added seam, normal color, undo */
|
|
|
|
|
if (G.main->versionfile <= 234) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
U.uiflag |= USER_GLOBALUNDO;
|
|
|
|
|
if (U.undosteps==0) U.undosteps=32;
|
|
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tv3d.edge_seam[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.edge_seam, 230, 150, 50, 255);
|
|
|
|
|
}
|
|
|
|
|
if(btheme->tv3d.normal[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.normal, 0x22, 0xDD, 0xDD, 255);
|
|
|
|
|
}
|
|
|
|
|
if(btheme->tv3d.face_dot[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.face_dot, 255, 138, 48, 255);
|
|
|
|
|
btheme->tv3d.facedot_size= 4;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 235) {
|
|
|
|
|
/* illegal combo... */
|
|
|
|
|
if (U.flag & USER_LMOUSESELECT)
|
|
|
|
|
U.flag &= ~USER_TWOBUTTONMOUSE;
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 236) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
/* new space type */
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->ttime.back[3]==0) {
|
|
|
|
|
btheme->ttime = btheme->tsnd; // copy from sound
|
|
|
|
|
}
|
|
|
|
|
if(btheme->text.syntaxn[3]==0) {
|
|
|
|
|
SETCOL(btheme->text.syntaxn, 0, 0, 200, 255); /* Numbers Blue*/
|
|
|
|
|
SETCOL(btheme->text.syntaxl, 100, 0, 0, 255); /* Strings red */
|
|
|
|
|
SETCOL(btheme->text.syntaxc, 0, 100, 50, 255); /* Comments greenish */
|
|
|
|
|
SETCOL(btheme->text.syntaxv, 95, 95, 0, 255); /* Special */
|
|
|
|
|
SETCOL(btheme->text.syntaxb, 128, 0, 80, 255); /* Builtin, red-purple */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 237) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
/* bone colors */
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tv3d.bone_solid[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.bone_solid, 200, 200, 200, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.bone_pose, 80, 200, 255, 80);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 238) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
/* bone colors */
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tnla.strip[3]==0) {
|
|
|
|
|
SETCOL(btheme->tnla.strip_select, 0xff, 0xff, 0xaa, 255);
|
|
|
|
|
SETCOL(btheme->tnla.strip, 0xe4, 0x9c, 0xc6, 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 239) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* Lamp theme, check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tv3d.lamp[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.lamp, 0, 0, 0, 40);
|
|
|
|
|
/* TEMPORAL, remove me! (ton) */
|
|
|
|
|
U.uiflag |= USER_PLAINMENUS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
if(U.obcenter_dia==0) U.obcenter_dia= 6;
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 241) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* Node editor theme, check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tnode.syntaxn[3]==0) {
|
|
|
|
|
/* re-uses syntax color storage */
|
|
|
|
|
btheme->tnode= btheme->tv3d;
|
|
|
|
|
SETCOL(btheme->tnode.edge_select, 255, 255, 255, 255);
|
|
|
|
|
SETCOL(btheme->tnode.syntaxl, 150, 150, 150, 255); /* TH_NODE, backdrop */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxn, 129, 131, 144, 255); /* in/output */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxb, 127,127,127, 255); /* operator */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxv, 142, 138, 145, 255); /* generator */
|
|
|
|
|
SETCOL(btheme->tnode.syntaxc, 120, 145, 120, 255); /* group */
|
|
|
|
|
}
|
|
|
|
|
/* Group theme colors */
|
|
|
|
|
if(btheme->tv3d.group[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.group, 0x10, 0x40, 0x10, 255);
|
|
|
|
|
SETCOL(btheme->tv3d.group_active, 0x66, 0xFF, 0x66, 255);
|
|
|
|
|
}
|
|
|
|
|
/* Sequence editor theme*/
|
|
|
|
|
if(btheme->tseq.movie[3]==0) {
|
|
|
|
|
SETCOL(btheme->tseq.movie, 81, 105, 135, 255);
|
|
|
|
|
SETCOL(btheme->tseq.image, 109, 88, 129, 255);
|
|
|
|
|
SETCOL(btheme->tseq.scene, 78, 152, 62, 255);
|
|
|
|
|
SETCOL(btheme->tseq.audio, 46, 143, 143, 255);
|
|
|
|
|
SETCOL(btheme->tseq.effect, 169, 84, 124, 255);
|
|
|
|
|
SETCOL(btheme->tseq.plugin, 126, 126, 80, 255);
|
|
|
|
|
SETCOL(btheme->tseq.transition, 162, 95, 111, 255);
|
|
|
|
|
SETCOL(btheme->tseq.meta, 109, 145, 131, 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* set defaults for 3D View rotating axis indicator */
|
|
|
|
|
/* since size can't be set to 0, this indicates it's not saved in .B.blend */
|
|
|
|
|
if (U.rvisize == 0) {
|
|
|
|
|
U.rvisize = 15;
|
|
|
|
|
U.rvibright = 8;
|
|
|
|
|
U.uiflag |= USER_SHOW_ROTVIEWICON;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 242) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* long keyframe color */
|
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
|
if(btheme->tact.strip[3]==0) {
|
|
|
|
|
SETCOL(btheme->tv3d.edge_sharp, 255, 32, 32, 255);
|
|
|
|
|
SETCOL(btheme->tact.strip_select, 0xff, 0xff, 0xaa, 204);
|
|
|
|
|
SETCOL(btheme->tact.strip, 0xe4, 0x9c, 0xc6, 204);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* IPO-Editor - Vertex Size*/
|
|
|
|
|
if(btheme->tipo.vertex_size == 0) {
|
|
|
|
|
btheme->tipo.vertex_size= 3;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile <= 243) {
|
|
|
|
|
/* set default number of recently-used files (if not set) */
|
|
|
|
|
if (U.recent_files == 0) U.recent_files = 10;
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile < 245 || (G.main->versionfile == 245 && G.main->subversionfile < 3)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
SETCOL(btheme->tv3d.editmesh_active, 255, 255, 255, 128);
|
|
|
|
|
}
|
|
|
|
|
if(U.coba_weight.tot==0)
|
|
|
|
|
init_colorband(&U.coba_weight, 1);
|
|
|
|
|
}
|
|
|
|
|
if ((G.main->versionfile < 245) || (G.main->versionfile == 245 && G.main->subversionfile < 11)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
for (btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* these should all use the same colour */
|
|
|
|
|
SETCOL(btheme->tv3d.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tipo.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tact.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tnla.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tseq.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tsnd.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->ttime.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ((G.main->versionfile < 245) || (G.main->versionfile == 245 && G.main->subversionfile < 11)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
for (btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* these should all use the same color */
|
|
|
|
|
SETCOL(btheme->tv3d.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tipo.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tact.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tnla.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tseq.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->tsnd.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
SETCOL(btheme->ttime.cframe, 0x60, 0xc0, 0x40, 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ((G.main->versionfile < 245) || (G.main->versionfile == 245 && G.main->subversionfile < 13)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
for (btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* action channel groups (recolor anyway) */
|
|
|
|
|
SETCOL(btheme->tact.group, 0x39, 0x7d, 0x1b, 255);
|
|
|
|
|
SETCOL(btheme->tact.group_active, 0x7d, 0xe9, 0x60, 255);
|
|
|
|
|
|
|
|
|
|
/* bone custom-color sets */
|
|
|
|
|
// FIXME: this check for initialised colors is bad
|
|
|
|
|
if (btheme->tarm[0].solid[3] == 0) {
|
|
|
|
|
/* set 1 */
|
|
|
|
|
SETCOL(btheme->tarm[0].solid, 0x9a, 0x00, 0x00, 255);
|
|
|
|
|
SETCOL(btheme->tarm[0].select, 0xbd, 0x11, 0x11, 255);
|
|
|
|
|
SETCOL(btheme->tarm[0].active, 0xf7, 0x0a, 0x0a, 255);
|
|
|
|
|
/* set 2 */
|
|
|
|
|
SETCOL(btheme->tarm[1].solid, 0xf7, 0x40, 0x18, 255);
|
|
|
|
|
SETCOL(btheme->tarm[1].select, 0xf6, 0x69, 0x13, 255);
|
|
|
|
|
SETCOL(btheme->tarm[1].active, 0xfa, 0x99, 0x00, 255);
|
|
|
|
|
/* set 3 */
|
|
|
|
|
SETCOL(btheme->tarm[2].solid, 0x1e, 0x91, 0x09, 255);
|
|
|
|
|
SETCOL(btheme->tarm[2].select, 0x59, 0xb7, 0x0b, 255);
|
|
|
|
|
SETCOL(btheme->tarm[2].active, 0x83, 0xef, 0x1d, 255);
|
|
|
|
|
/* set 4 */
|
|
|
|
|
SETCOL(btheme->tarm[3].solid, 0x0a, 0x36, 0x94, 255);
|
|
|
|
|
SETCOL(btheme->tarm[3].select, 0x36, 0x67, 0xdf, 255);
|
|
|
|
|
SETCOL(btheme->tarm[3].active, 0x5e, 0xc1, 0xef, 255);
|
|
|
|
|
/* set 5 */
|
|
|
|
|
SETCOL(btheme->tarm[4].solid, 0xa9, 0x29, 0x4e, 255);
|
|
|
|
|
SETCOL(btheme->tarm[4].select, 0xc1, 0x41, 0x6a, 255);
|
|
|
|
|
SETCOL(btheme->tarm[4].active, 0xf0, 0x5d, 0x91, 255);
|
|
|
|
|
/* set 6 */
|
|
|
|
|
SETCOL(btheme->tarm[5].solid, 0x43, 0x0c, 0x78, 255);
|
|
|
|
|
SETCOL(btheme->tarm[5].select, 0x54, 0x3a, 0xa3, 255);
|
|
|
|
|
SETCOL(btheme->tarm[5].active, 0x87, 0x64, 0xd5, 255);
|
|
|
|
|
/* set 7 */
|
|
|
|
|
SETCOL(btheme->tarm[6].solid, 0x24, 0x78, 0x5a, 255);
|
|
|
|
|
SETCOL(btheme->tarm[6].select, 0x3c, 0x95, 0x79, 255);
|
|
|
|
|
SETCOL(btheme->tarm[6].active, 0x6f, 0xb6, 0xab, 255);
|
|
|
|
|
/* set 8 */
|
|
|
|
|
SETCOL(btheme->tarm[7].solid, 0x4b, 0x70, 0x7c, 255);
|
|
|
|
|
SETCOL(btheme->tarm[7].select, 0x6a, 0x86, 0x91, 255);
|
|
|
|
|
SETCOL(btheme->tarm[7].active, 0x9b, 0xc2, 0xcd, 255);
|
|
|
|
|
/* set 9 */
|
|
|
|
|
SETCOL(btheme->tarm[8].solid, 0xf4, 0xc9, 0x0c, 255);
|
|
|
|
|
SETCOL(btheme->tarm[8].select, 0xee, 0xc2, 0x36, 255);
|
|
|
|
|
SETCOL(btheme->tarm[8].active, 0xf3, 0xff, 0x00, 255);
|
|
|
|
|
/* set 10 */
|
|
|
|
|
SETCOL(btheme->tarm[9].solid, 0x1e, 0x20, 0x24, 255);
|
|
|
|
|
SETCOL(btheme->tarm[9].select, 0x48, 0x4c, 0x56, 255);
|
|
|
|
|
SETCOL(btheme->tarm[9].active, 0xff, 0xff, 0xff, 255);
|
|
|
|
|
/* set 11 */
|
|
|
|
|
SETCOL(btheme->tarm[10].solid, 0x6f, 0x2f, 0x6a, 255);
|
|
|
|
|
SETCOL(btheme->tarm[10].select, 0x98, 0x45, 0xbe, 255);
|
|
|
|
|
SETCOL(btheme->tarm[10].active, 0xd3, 0x30, 0xd6, 255);
|
|
|
|
|
/* set 12 */
|
|
|
|
|
SETCOL(btheme->tarm[11].solid, 0x6c, 0x8e, 0x22, 255);
|
|
|
|
|
SETCOL(btheme->tarm[11].select, 0x7f, 0xb0, 0x22, 255);
|
|
|
|
|
SETCOL(btheme->tarm[11].active, 0xbb, 0xef, 0x5b, 255);
|
|
|
|
|
/* set 13 */
|
|
|
|
|
SETCOL(btheme->tarm[12].solid, 0x8d, 0x8d, 0x8d, 255);
|
|
|
|
|
SETCOL(btheme->tarm[12].select, 0xb0, 0xb0, 0xb0, 255);
|
|
|
|
|
SETCOL(btheme->tarm[12].active, 0xde, 0xde, 0xde, 255);
|
|
|
|
|
/* set 14 */
|
|
|
|
|
SETCOL(btheme->tarm[13].solid, 0x83, 0x43, 0x26, 255);
|
|
|
|
|
SETCOL(btheme->tarm[13].select, 0x8b, 0x58, 0x11, 255);
|
|
|
|
|
SETCOL(btheme->tarm[13].active, 0xbd, 0x6a, 0x11, 255);
|
|
|
|
|
/* set 15 */
|
|
|
|
|
SETCOL(btheme->tarm[14].solid, 0x08, 0x31, 0x0e, 255);
|
|
|
|
|
SETCOL(btheme->tarm[14].select, 0x1c, 0x43, 0x0b, 255);
|
|
|
|
|
SETCOL(btheme->tarm[14].active, 0x34, 0x62, 0x2b, 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ((G.main->versionfile < 245) || (G.main->versionfile == 245 && G.main->subversionfile < 16)) {
|
|
|
|
|
U.flag |= USER_ADD_VIEWALIGNED|USER_ADD_EDITMODE;
|
|
|
|
|
}
|
|
|
|
|
if ((G.main->versionfile < 247) || (G.main->versionfile == 247 && G.main->subversionfile <= 2)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
/* adjust themes */
|
|
|
|
|
for (btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
char *col;
|
|
|
|
|
|
|
|
|
|
/* IPO Editor: Handles/Vertices */
|
|
|
|
|
col = btheme->tipo.vertex;
|
|
|
|
|
SETCOL(btheme->tipo.handle_vertex, col[0], col[1], col[2], 255);
|
|
|
|
|
col = btheme->tipo.vertex_select;
|
|
|
|
|
SETCOL(btheme->tipo.handle_vertex_select, col[0], col[1], col[2], 255);
|
|
|
|
|
btheme->tipo.handle_vertex_size= btheme->tipo.vertex_size;
|
|
|
|
|
|
|
|
|
|
/* Sequence/Image Editor: colors for GPencil text */
|
|
|
|
|
col = btheme->tv3d.bone_pose;
|
|
|
|
|
SETCOL(btheme->tseq.bone_pose, col[0], col[1], col[2], 255);
|
|
|
|
|
SETCOL(btheme->tima.bone_pose, col[0], col[1], col[2], 255);
|
|
|
|
|
col = btheme->tv3d.vertex_select;
|
|
|
|
|
SETCOL(btheme->tseq.vertex_select, col[0], col[1], col[2], 255);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (G.main->versionfile < 250) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
/* this was not properly initialized in 2.45 */
|
|
|
|
|
if(btheme->tima.face_dot[3]==0) {
|
|
|
|
|
SETCOL(btheme->tima.editmesh_active, 255, 255, 255, 128);
|
|
|
|
|
SETCOL(btheme->tima.face_dot, 255, 133, 0, 255);
|
|
|
|
|
btheme->tima.facedot_size= 2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* DopeSheet - (Object) Channel color */
|
|
|
|
|
SETCOL(btheme->tact.ds_channel, 82, 96, 110, 255);
|
|
|
|
|
SETCOL(btheme->tact.ds_subchannel, 124, 137, 150, 255);
|
|
|
|
|
/* DopeSheet - Group Channel color (saner version) */
|
|
|
|
|
SETCOL(btheme->tact.group, 79, 101, 73, 255);
|
|
|
|
|
SETCOL(btheme->tact.group_active, 135, 177, 125, 255);
|
|
|
|
|
|
|
|
|
|
/* Graph Editor - (Object) Channel color */
|
|
|
|
|
SETCOL(btheme->tipo.ds_channel, 82, 96, 110, 255);
|
|
|
|
|
SETCOL(btheme->tipo.ds_subchannel, 124, 137, 150, 255);
|
|
|
|
|
/* Graph Editor - Group Channel color */
|
|
|
|
|
SETCOL(btheme->tipo.group, 79, 101, 73, 255);
|
|
|
|
|
SETCOL(btheme->tipo.group_active, 135, 177, 125, 255);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* adjust grease-pencil distances */
|
|
|
|
|
U.gp_manhattendist= 1;
|
|
|
|
|
U.gp_euclideandist= 2;
|
|
|
|
|
|
|
|
|
|
/* adjust default interpolation for new IPO-curves */
|
|
|
|
|
U.ipo_new= BEZT_IPO_BEZ;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (G.main->versionfile < 250 || (G.main->versionfile == 250 && G.main->subversionfile < 1)) {
|
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
|
|
|
|
|
|
/* common (new) variables, it checks for alpha==0 */
|
|
|
|
|
ui_theme_init_new(btheme);
|
|
|
|
|
|
|
|
|
|
if(btheme->tui.wcol_num.outline[3]==0)
|
|
|
|
|
ui_widget_color_init(&btheme->tui);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* GL Texture Garbage Collection (variable abused above!) */
|
|
|
|
|
if (U.textimeout == 0) {
|
|
|
|
|
U.texcollectrate = 60;
|
|
|
|
|
U.textimeout = 120;
|
|
|
|
|
}
|
|
|
|
|
if (U.memcachelimit <= 0) {
|
|
|
|
|
U.memcachelimit = 32;
|
|
|
|
|
}
|
|
|
|
|
if (U.frameserverport == 0) {
|
|
|
|
|
U.frameserverport = 8080;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* funny name, but it is GE stuff, moves userdef stuff to engine */
|
|
|
|
|
// XXX space_set_commmandline_options();
|
|
|
|
|
/* this timer uses U */
|
|
|
|
|
// XXX reset_autosave();
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
