octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patches for autopositioning of labels in fltk


From: Ben Abbott
Subject: Re: Patches for autopositioning of labels in fltk
Date: Tue, 14 Dec 2010 19:25:28 -0500

On Dec 14, 2010, at 2:42 PM, logari81 wrote:

> On Mon, 2010-12-13 at 19:49 -0500, Ben Abbott wrote:
>> On Dec 13, 2010, at 4:32 PM, logari81 wrote:
>> 
>>> 
>>>>> 
>>>>> Ok. I get the same result in the FLTK window as is seen in the png file.
>>>>> 
>>>>> Another short test ...
>>>>> 
>>>>> clf
>>>>> ht = text (0.5, 0.5, "Hello World");
>>>>> set (gca, "xlabel", ht)
>>>>> get (ht, "positionmode")
>>>>> ans = manual
>>>>> get (ht, "position")
>>>>> ans =   0.50000   0.50000   0.00000
>>>>> 
>>>>> If I then force the position mode ...
>>>>> 
>>>>> set (hx, "positionmode", "auto")
>>>>> get (hx, "position")
>>>>> ans =   0.500000  -0.052598  -1.000000
>>>>> 
>>>>> ... which indicates the correct position.  I've occasionally had problems 
>>>>> with builds on MacOS X. I'll try the same using Ubuntu via VirtualBox and 
>>>>> report back later.
>>>>> 
>>>>> Ben
>>>> 
>>>> Your changes worked for me (as they do for you) on Ubuntu. After a fresh 
>>>> build and carefully apply the changes on MacOS X, they work there as well.
>>>> 
>>>> The problem with the third plot is that the x-position of the labels is 
>>>> set in a lazy fashion. It isn't set until after the script is done. If a 
>>>> "drawnow" is included after "hx = xlabel ('xlabel')", it works correctly.
>>>> 
>>>> clf
>>>> px = get (xlabel ('hello world'), 'position')
>>>> px =   0   0   0
>>>> drawnow
>>>> get (get (gca, "xlabel"), "position")
>>>> ans =   0.50000  -0.05260   0.00000
>>>> 
>>>> Running matlab I get  "0.4988   -0.0658    1.0001" both times.
>>>> 
>>>> Is this something that can be easily fixed, or should a bug report be 
>>>> added to the tracker?
>>>> 
>>>> Ben
>>> 
>>> hm, ok I now see the problem. Actually the calculation of the xlabel
>>> position is done in opengl_renderer::draw_axes, so the question now is
>>> where to trigger its execution. What are the pros and contras for doing
>>> it in the backend (graphics.h / graphics.cc) or in the frontend
>>> ({xyz}label.m, title.m)?
>>> 
>>> Actually this change makes sense only for the fltk backend, since
>>> gnuplot cannot return information about labels' position anyway.
>>> 
>>> Do you have any suggestion on this so that we can finalize this patch
>>> and move forward?
>>> 
>>> regards,
>>> 
>>> Kostas
>> 
>> It is possible provide offset information for to the gnuplot backend for 
>> xlabel, ylabel, zlabel, and the title, so it may be possible to implement 
>> something useful, but it isn't likely to produce the exact behavior desired. 
>> The trick is (1) determining the default position of these text objects ... 
>> which I've done this before, and (2) determining the extents of the ytick 
>> labels (which is more difficult). Perhaps it is best to ignore the gnuplot 
>> backend and focus on OpenGL.
>> 
>> I don't think the m-files have access to the routines needed to determine 
>> the extents of text objects, so I think the job will need to be done in the 
>> backend.
>> 
>> Ben
>> 
> A very simple solution that I have tried in the frontend is adding a
> __fltk_redraw__()
> just after the set() call in __axis_label__.m . At least on my
> installation it seems to work fine with your test script.
> 
> I could easily implement the same in the backend as well. But it is a
> bit more difficult to achieve finer control of the situation and request
> only the modified axis to be redrawn.
> 
> What do you think? Do you see any performance issues due to excessive
> redraw calls?
> 
> Kostas

This is too far out of my sandbox for me to offer an informed opinion.

So, I've cc'd some of the developer's who have contributed to the OpenGL 
backend.

Ben



reply via email to

[Prev in Thread] Current Thread [Next in Thread]