On 29/06/2013, at 3:47 PM, Campbell Barton wrote:
Mono follows an MS spec for the language runtime (CLR), not sure what
the second program you refer to is.
At least the technology isn't owned by MS and its open-source.
People may be wary of using MS derived technology but from what I can
On Wed, Jun 26, 2013 at 11:53 PM, Campbell Barton ideasma...@gmail.comwrote:
Noticed node placement bug this morning,
fixed r57813.
Unfortunately, r57813 did not fix the node-placement bug on retina, because
the retina bug is related to U.pixelsize ... (see below)
Though IMHO using DPI to
On Fri, Jun 28, 2013 at 11:36 PM, David Jeske dav...@gmail.com wrote:
In the meantime, I did some digging and I don't think the retina
node-placement location bug is [not] related to pixelsize mouse-transforms.
I think it's related to drawing code that does not handle pixelsize.
UGH, sorry,
sorry, nub dev question.. I noticed these entires in rna_wm.c with tooltips
saying X positions are vertical, and Y positions are horizontal...
Is this the tooltip mistake it seems like to me, or is there some
non-obvious reason for this?
prop = RNA_def_property(srna, mouse_x, PROP_INT,
Hi Alex,
The libs will not be compatible. All versions of MSVC since 2010 write a
version string into libs. And all versions since 2012 check this string.
You can not link to libs compiled with a older version.
Also I can just repeat myself: We don't want to switch to 2013.
I would just like
TINY (hopefully uncontroversial) patch to fix up to parent usability in
the node-editor (and improve a tooltip)
http://projects.blender.org/tracker/index.php?func=detailaid=35910group_id=9atid=127
___
Bf-committers mailing list
Bf-committers@blender.org
Hi;
I know this breaks every rule of the Blender user interface.
However please take a moment (or two) and think about
these 2 alternatives for showing the Weight paint value
in weight Paint mode:
http://pasteall.org/pic/show.php?id=54510
On the left side: the bar changes its color from
On 29/06/2013 11:04, Gaia wrote:
Hi;
I know this breaks every rule of the Blender user interface.
However please take a moment (or two) and think about
these 2 alternatives for showing the Weight paint value
in weight Paint mode:
http://pasteall.org/pic/show.php?id=54510
On the
Hi Brecht,
Buildbot, scons compile error in Windows:
Compiling == 'blf.c'
blf.c
source\blender\blenlib\BLI_threads.h(38) : fatal error C1083: Cannot open
include file: 'pthread.h': No such file or directory
scons: building terminated because of errors.
No idea why... Windows include files is
Hi,
I tried to add DPI scaling and retina (pixelsize) support in the least
intrusive way for the code. The button views (layout engine) behave very nice
for it. Similarly easy was for 3D views, FCurve editor, Image, etc.
However, Node Editor is an exception. It uses 2D elements (nodes) and UI
Is there any more information you have about this, like a bug report
or a description of when this happens? Now it's adding an XXX comment
but there's no information for someone who might want to fix the
actual bug.
On Sat, Jun 29, 2013 at 10:38 AM, Gaia Clary
gaia.cl...@machinimatrix.org wrote:
Fixed now.
On Sat, Jun 29, 2013 at 12:05 PM, Ton Roosendaal t...@blender.org wrote:
Hi Brecht,
Buildbot, scons compile error in Windows:
Compiling == 'blf.c'
blf.c
source\blender\blenlib\BLI_threads.h(38) : fatal error C1083: Cannot open
include file: 'pthread.h': No such file or
Fixed now, these were indeed wrong, just a silly typo/mixup.
On Sat, Jun 29, 2013 at 8:46 AM, David Jeske dav...@gmail.com wrote:
sorry, nub dev question.. I noticed these entires in rna_wm.c with tooltips
saying X positions are vertical, and Y positions are horizontal...
Is this the tooltip
Hi,
This line:
y = (ypixels = 39.0f * UI_DPI_FAC) ? (ypixels - 10.0f * UI_DPI_FAC) :
29.0f * UI_DPI_FAC;
Is really an exception. It was code using hardcode pixel values before.
So it was this:
y = (ypixels = 39.0f) ? (ypixels - 10.0f) : 29.0f;
In order to make it respect DPI scaling, the
Hi,
As I explained before, I made MacBook retina to work for HiDPI in the least
intrusive way for our code. But I also had to do it in a way it would work for
everyone.
That meant I had to make two things work independently:
- DPI scaling for UIs in general.
- Apple's HiDPI implementation
i got a .blend file from a customer but i can not use that within a bug
report.
The only hints i have so far:
1.) right after the (rigged) object enters weight Paint mode, i can see
in the debugger:
me-totselect = 1
me-mselect = NULL
one vertex has the select flag enabled.
2.) The problem
Hi,
I had a look at this some months ago. For Windows there is a system
DPI that you can configure as a user and there's an API to query it.
It does not do this OS X trick with the 2x pixel size and decoupled
desktop coordinates, all coordinates are in actual pixels. Here's the
info:
Hi,
A good guideline for UI design is to always consider options and choices to be
done only in a last unfortunate case when nothing else can work.
If you need to patch design to make it usable, we better go back to look at the
core design concepts itself.
-Ton-
Here are some alternatives which could solve potential problems with
custom weight paint colors:
http://pasteall.org/pic/show.php?id=54515
What do you think ? (my favorite is now the example in the middle).
-gaia-
On 29.06.2013 11:32, Ronan Ducluzeau aka zeauro wrote:
On 29/06/2013
Hey Brecht,
Note sure if it would help, but on Linux for X dpi, perhaps these
options might be of help?:
Option UseEdidDpi FALSE
Option DPI 96x96
I need them in my xorg.conf here, but in my case, it is because my
monitor reports poor info. Anyways, just a side
Hi,
Been busy all week with other stuff, interesting long thread :)
Quick observations below:
1) Include opt-in usage and automatic crash reporting in *every* blender
build, and a web dashboard to live usage/crash stats to devs and the
community.
I always wondered what other
It's not a reliable value to use, because it's not correctly reported
by many monitors, and does not actually correspond to the DPI assumed
by any other UI toolkit. I've looked for the right value for quite a
while, but only conclusion I can find is that none of
Gnome/KDE/Xfce/GTK/Qt/.. have
I think there are at least three topics worth discussing here..
(a) how should blender appear on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)
(b) how should the Blender code achieve this..
(c) how is hidpi detected on
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote:
It's not a reliable value to use, because it's not correctly reported
by many monitors, and does not actually correspond to the DPI assumed
by any other UI toolkit. I've looked for the right value for quite a
while, but only
I think that the best place to show weight color of brush is probably
brush circle, itself.
Do you think it is possible to have an overlay feature for that in
Weight Paint mode ?
Weight Paint Mode is the only one to have no overlay feature.
Sculpt, Texture and Vertex Paint modes are sharing the
Hi,
(a) how should blender appear on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)
That's supported and working already even!
(b) how should the Blender code achieve this..
Given the fact every pixel in our UI is opengl
Enabling overlay, even texture access for weight painting is not too hard.
I can probably add it after release.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Finally, I am not sure if overlay is needed. There is already radial
control to set weight of brush.
Maybe it is possible just to color what is already there.
http://www.pasteall.org/pic/show.php?id=54536
But as gaia said; there is a keymap conflict when we use a rigged model.
W keymap for
It would be probably better to display only one color.
http://www.pasteall.org/pic/show.php?id=54544
-ronan-
On 29/06/2013 18:53, Antony Riakiotakis wrote:
Enabling overlay, even texture access for weight painting is not too hard.
I can probably add it after release.
From a purely UX point of view the multicolor mockups are better even
though they may look worse in the UI. It shows you without having to
play with the widget exactly where you need to be at a glance. The other
one is an improvement over the current solution, but not as nice overall.
I guess
Looking away from the details for a moment.. It would be helpful to have a
clear Blender HiDPI philosophy, so we know the right way to fix these
bugs... I'll take a shot at this now...
If I understand your philosophy Ton, I think it is:
1) Editors where 2d pixels are not edited (everything
On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org wrote:
1) Include opt-in usage and automatic crash reporting in *every* blender
build, and a web dashboard to live usage/crash stats to devs and the
community.
I always wondered what other projects/companies do with such
Campbell Barton wrote
theres not much incentive to
rewrite - only for the sake of cleaner code.
I totally understand and wouldn't argue they should be, never touch a
working system and all that. Having the TODO make pep 8 compliant comment
in the header is also a good hint that they are perhaps
On Jun 29, 2013 7:01 AM, Ton Roosendaal t...@blender.org wrote:
If you need to patch design to make it usable, we better go back to look
at the core design concepts itself.
While the 3 current operator UIs (menu-bar modal text, tools-opperator
panel, and F6 floating panel) are usable.. they
When I fix bugs in unfamiliar projects, I spend 90% of my time getting it
to build and playing sherlock holmes tracking down weak-linkages like
dynamic-typed variables and weak-linkages (like strings used as enums in C)
-- and 10% of my time actually trying to understand or fix code.
In strong
On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton ideasma...@gmail.comwrote:
2) Increase community leverage, sharing, library asset encapsulation --
more bridges between pro-artists and amateur blender pilots.
Material-sharing is being figured out. I'd like to be able to enapsulate a
more
I think that you've hit upon two of the important factors here:
- familiarity
- discoverability
To which I would also add
- refactorability (is that a word? :-)
Those familiar with a project might not see the value in strong typing
simply because it doesn't add much to their personal
37 matches
Mail list logo
