gmane.comp.openoffice.devel.gsl

new Apache OpenOffice.org mail list to replace this list

2011-11-02T16:23:59

Invitation to connect on LinkedIn

Hirano Kazunari — 2011-09-28T11:14:52

I'd like to add you to my professional network on LinkedIn.

- Hirano

Hirano Kazunari
I18n/L10n Community Contributor at OpenSolaris
Japan

Confirm that you know Hirano Kazunari:
https://www.linkedin.com/e/s56nud-gt47xdbt-1n/isd/4381518658/aDWjN2Wz/?hs=false&tok=13XO_APvX2-QU1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/s56nud-gt47xdbt-1n/v-zIyAycNHEpG0mJmE2OMuPlDsipeIM3MJ3/goo/dev%40gsl%2Eopenoffice%2Eorg/20061/I1517857375_1/?hs=false&tok=0PYLLe77v2-QU1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

SAL_LAYOUT_BIDI_STRONG

tora - Takamichi Akiyama — 2011-05-20T11:39:33

Hi,

What do you think of the following code?

http://hg.services.openoffice.org/OOO330/file/8601acbe0e6c/vcl/source/gdi/outdev3.cxx#l5827

   5827         if( pStr >= pEnd )
   5828             nLayoutFlags |= SAL_LAYOUT_BIDI_STRONG;

When rStr is "0" i.e. 0x0030, SAL_LAYOUT_BIDI_STRONG is being set.

I have not yet confirmed what SAL_LAYOUT_BIDI_STRONG means, but its name implies something BIDI is enabled. Likewise, the line 5855

Best regards,
Tora

Re: drawing outside

Dmitry A. Ashkadov — 2011-04-15T15:52:00

Can I create a small window (class Window from vcl module) outside 
ruler? This window should be able to float over others GUI elements. Is 
it possible?

15.04.2011 16:47, Philipp Lohmann пишет:

Re: drawing outside

Philipp Lohmann — 2011-04-15T12:47:06

Hi,

this is generally not possible. You can only draw within your window 
bounds. However there is a method to draw also in the region that is 
occluded by the child windows of a window (thereby painting on those 
child windows, too). This can be done using the 
Window::SetParentClipMode( PARENTCLIPMODE_NOCLIP ) method.

The normal ruler however does not do that AFAIK; it seems it simply 
draws to the correct window. For details see the SvxRuler class: 
svx/source/dialog/svxruler.cxx in the method SvxRuler::DrawLine_Impl.

Just my 2 cents, pl

On 15.04.11 14:11, Dmitry A. Ashkadov wrote:

drawing outside

Dmitry A. Ashkadov — 2011-04-15T12:11:16

Hello!

Can I draw some parts of GUI element outside it (its window)? For 
example, how can ruler draw over document field? Is it possible?

Thanks.

Askbangladesh.com iinvitation!

2011-04-09T10:09:08

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b — 2011-02-21T16:44:42

Hi,

Answering to myself : I finaly got a screenshot of what I suppose to  
be "the flickering"  : http://eric.bachard.free.fr/patches/OOo4Kids/ 
linux_arm/flicker_linux_arm.png

HTH to visualize the problem more precisely


Thanks,
Eric

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric — 2011-02-20T22:43:12

Philipp Lohmann a écrit :

Hi Philipp,



1)


OK, using virdev.hxx

2)


Ok. More precisely, I added UpdateAffectedArea as private method in 
BackingWindow class, and works perfectly.

3)


Done

4)

Done, using COL_TRANSPARENT (found somewhere in tools)

5)


Ok, done.

6)



What does the Draw method ?

I was not sure, so I added a parameter in the signature ( like 
Point(0,0) per see the compiler cry and propose me correct candidates, 
and I found the header location <vcl/fixed.hxx> (yes, I'm lazy sometimes :)

So I had a look at the implementation and the Draw method does nothing 
(see vcl/source/control/fixed.cxx:634).

So I removed the action below and it works the same. At least, is seems to.

7)



Works : I can draw/hide text without use Show(), Hide()


... but unfortunaly I still got the flicker. Less, but still flicker 
(tested on Linux).

What did i wrong ? (below, some important lines, just in case I did 
something completely wrong). Thanks in advance for any hint.


Kind regards,
Eric




vo

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b — 2011-02-20T13:36:59

Le 17 févr. 11 à 13:01, Philipp Lohmann a écrit :



Hi Philipp,




If this can help, most of the flicker occurs whith  Hide() method.  
Don't ask me why :)




Thank you very much for this explanation, I'll start today with that,  
and I hope I'll make progress in the coming week.





I'm not sure to understand : when the mouse cursor rolls over one  
button, it it not over the text area, but on the button area, no ? So  
maybe accessibility will continue to work ? (but maybe I missed  
something).

Anyway, I consider the flicker as a blocker (avoiding us to release  
1.2) and I'd like to see how things work once fixed.


Thanks again for your golden advices :)

Eric

Re: Refresh issue with FixedText controls (Linux and Windows only)

Philipp Lohmann — 2011-02-17T12:01:02

Hi,

On 2/16/11 9:23 AM, eric wrote:
You would have a VirtualDevice that spans the area where you currently 
have "flickering" problems. So when the need to change the contents of 
that area arises, you can do all painting in that backbuffer and only 
copy it to window when you're done.

So like this:

#include "vcl/virdev.hxx"

void UpdateAffectedArea()
{
     VirtualDevice aDev;
     aDev.SetBackground( Color( < my background color > ) );
     aDev.SetOutputSizePixel( < my size in pixel > );

     maFixedText.Draw( &aDev, <position>, <size>, <flags> );

     maWindow.DrawOutDev(
<position in window>, <my size in pixel>,
         Point( 0, 0 ), <my size in pixel>,
&aDev );

}

However there is a caveat: since you do not have a real FixedText 
control there anymore, accessibility will not work for this area, so no 
screen readers etc. Not worth dropping that for a little flicker IMHO, 
but possible.

Kind regards, pl

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric — 2011-02-16T08:23:41

Philipp Lohmann a écrit :

Hi Philipp,




After lot of tries, and some algo improvments, I fear this will be the 
only relible solution : flickering is always present on both Windows and 
Linux.

Could you please give me some tracks, or point me existing example in 
the code, to implement this VirtualDevice ? (of course the code will be 
reversed if you consider it interesting for OpenOffice.org)



Indeed: applying your suggestion, helped, but flickering is still present :/


Kind regards,
Eric

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b — 2011-01-25T08:41:14

Le 24 janv. 11 à 18:24, Philipp Lohmann a écrit :



Hi Philipp,




Ok.




Is it possible to use double buffering on Windows and Linux too .. or  
not ?




That's what I thought after some tries : Mac OS X is the only one  
using true double-buffering. I must admit in my mind (and I was  
wrong) Windows should, but looks like it does not :-/




If I understand you correctly, you want to say that, on Windows and  
Linux, only double-buffering emulation is possible ?

The "emulation" solution look interesting, but looks a bit  
complicated, and on slow machines (like XO) I'm not sure it will work  
well. Last but not least, maybe there is some hidden drawback.




Ok,  I'll try what you suggest. I was wondering which one was the  
most costly at runtime : only one or set all and Show() / Hide() only  
one.




Indeed



Ah, I missed this point.





Your explanation is extremely interesting : I had no clue where  
cycles were lost, and the way transparency works explains a lot.





I got some time today

Re: Refresh issue with FixedText controls (Linux and Windows only)

Philipp Lohmann — 2011-01-24T17:24:48

Hi,

IMHO this is going to flicker somewhat whatever you do, since you need 
to erase the FixedText and the paint another one.

On the Mac you see this not because all drawing is double buffered; you 
do the "flickering" stuff in the back buffer which then gets copied in a 
single step when the mac comes around to update the actual window.

If you wanted to emulate this behavior on all platforms you could have 
your own control that does this using a VitualDevice to prepare its text 
and then only copy that to the window when the ::Paint method gets 
called. But that is probably a bit overblown.

You could also simplify things by not having different FixedTexts but 
using only one, calling SetText on that one FixedText when you need to 
change the text. This will also flicker at least a little since here 
also the window needs to get erased and then the new text drawn. But it 
will save a lot of clip region operations (removing the FixedText from 
the parents clip region and inserting the other one) which wi

Refresh issue with FixedText controls (Linux and Windows only)

eric b — 2011-01-18T08:51:14

Hi,

I have refresh ( flickering ?) issue with FixedText controls in  
Toolbox, but only on Windows and Linux.  On Mac OS X, things are  
perfect, no problem.

Specifications are :

Let's consider a rectangle (for instance, a button), in a toolbox  
object.
* when the mouse cursor rolls over on button, the  
VCLEVENT_TOOLBOX_HIGHLIGHT is sent when entering in the button  
rectangle.
* when the mouse cursor goes out of the area, the  
VCLEVENT_TOOLBOX_HIGHLIGHTOFF  is sent.

Receive VCLEVENT_TOOLBOX_HIGHLIGHT triggers a   aFixedText.Show()
Receive VCLEVENT_TOOLBOX_HIGHLIGHTOFF triggers all FixedText controls  
to be hidden ( e.g.  aFixedText.Hide() )

So when the mouse cursor is moved from left to right, we see the  
following events occur :

VCLEVENT_TOOLBOX_HIGHLIGHT is catched, next is  
VCLEVENT_TOOLBOX_HIGHLIGHTOFF ... VCLEVENT_TOOLBOX_HIGHLIGHT ... and  
so on, alternatively.

The result is :
no text shown ... show fixed text1  .. hide all fixed text ... show  
fixed text2 ... hide alll

The relevant co

Re: QuickHelpText and other methods

eric — 2010-12-30T19:29:15

Hi Philipp,

Apologies for the long delay, but found no student to work on that, so I 
  finaly did the work myself (last week).


Philipp Lohmann a écrit :


[...cut...]


Indeed. In the workwindow, itself using a DecoToolbox.



Works perfectly, thanks a lot for your -one more time - golden advices :)


Works perfectly either !




To share everything, I explained what i did on a wiki page (not up to 
date, but I'll add new screenshots very soon)

The link : http://wiki.ooo4kids.org/index.php/NewStartCenterBehavior


Thank you very much, and Seasons Greatings :)
Eric

Re: Resignation from co-lead

Kazunari Hirano — 2010-10-26T13:22:43

Thank you! Behrens san

Congratulations! Duerr san

We are looking forward to going forward with "Ideographic Variation
Sequences" support :)

Thanks,
khirano

Re: Resignation from co-lead

Thorsten Behrens — 2010-10-26T12:25:33

Hi Herbert,

heh, it was not my intention to diminish your work. Sorry if it came
across in that way - you clearly rock in multiple areas. :)

Cheers,

Re: Resignation from co-lead

Herbert Duerr — 2010-10-26T10:20:35

Hello Thorsten, hi GSL community,

On Oct 25, 2010, at 11:34 AM, Thorsten Behrens wrote:

I'm also with mixed emotions because of the circumstances of this divorce. The story of the divided communities saddens me a lot and so I'd rather not gain anything from the breakup.

On the other hand I'm not gaining from it because ego-boosting titles mean almost nothing to me and I dislike politics especially in technical contexts. I enjoy solving technical problems and working toward a positive user experience with our product.


Ditto.


I appreciate your endorsement and the compliment. I see my scope as being much broader though. My specialities are i18n, text, graphics, platform integration, algorithms, performance, debugging and backward compatibility. I return the compliment by admiring your marvelous work on the alpha outputdevice, the integration of third party code such as xpdf, agg or vigra and doing some other useful stuff ;-)

Herbert

Re: Resignation from co-lead

Philipp Lohmann — 2010-10-25T09:58:10

Thank you for your many years of dedicated work contributing to 
OpenOffice.org. The gsl project certainly couldn't have wished for a 
better Co-Lead; and certainly the fission of our community is regrettable.

I fully endorse the nomination of Herbert as your successor.

Kind regards, pl

On 10/25/10 11:34 AM, Thorsten Behrens wrote:

Resignation from co-lead

Thorsten Behrens — 2010-10-25T09:34:50

Dear gsl hackers, project leads of OOo -

it is with mixed emotions, that I hereby resign from my role as a gsl
co-lead, in which I served since 2007. My hopes that Oracle would
join TDF have sadly not come to pass.

As I believe in change, I will focus my energies on LibreOffice,
going forward.

At the same time, I would like to personally say thank you to all of
the great people, that I was lucky enough to meet in my nine years
with OOo - I learned a lot from you, and many of you tried hard to
change the project from the inside.

I propose Herbert Duerr as my successor - Herbert works on OOo even
longer than I do, and continues to do miracles to the font and layout
engines.

Best regards,