Re: [api-dev] use of css.awt.UnoControlScrollBarModel

2006-05-16 Thread Frank Schönheit - Sun Microsystems Ger many
Hi Paolo,

 In spite of this, reading the IDL description it seems that all should happen 
 automatically, without listeners or event binding, infact:
 
 css.awt.UnoControlScrollBarModel
 ---
 boolean LiveScroll;
 Description 
 specifies the scrolling behaviour of the control.  
 true means, that when the user moves the slider in the scroll bar, the 
 content 
 of the window is updated immediately. false means, that the window is only 
 updated after the user has released the mouse button. 
 Since  
 OpenOffice 2.0.0

As I said elsewhere in the thread, the documentation is misleading here.
In fact, the property controls how events are fired. Reactions on those
events are up to the client code. (You can use scrollbars for more than
for scrolling windows. For instance, you can bind them to spreadsheet
cells :)

i would expect attach a dialog window or frame to it ? 
how would you 
implement both horizontal and vertical slides
 
 Perhaps this should e matter of an RFE
 Currently the css.awt.ScrollBarOrientation constant group offers only:
 HORIZONTAL and VERTICAL
 the BOTH option is missing.

Hmm? How would you expect such a scrollbar to look like? How would you
expect a user to operate it?

In all widget programming I ever did, the model is more or less like this:

+--+ +-+
| (1)  | |^| (2)
|  | | |
|  | | |
|  | | |
|  | | |
|  | | |
|  | | |
|  | |v|
+--+ +-+
+--+
||   (3)||
+--+

A main window (1) which contains the to-be-scrolled content, a vertical
scrollbar (2), and a hortizontal scrollbar (3) - all three having the
same parent, instead of being children of each other.

There are toolkits which allow you to knit (2) and (3) with (1) so that
scrolling happens automatically. But currently, AWT, OpenOffice.org's
UNO-based toolkit, does not belong into this group.

 The hope would be that the developer that have implemented this thing is 
 reading us.

The LiveScroll property was implemented by me :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[api-dev] Running OpenOffice hidden without xvfb

2006-05-16 Thread Tobias Krais
Hi ML,

I have one more problem with my OO document converter in java. It is now
finished and I am calling this little jar file in linux from the
commandline. My goal is to convert a document on a server without X.

With an X server / xvfb it works without problems. But without it always
says it wants to connect to X. Is there really no other possibility than
installing xvfb? Why is X needed?

Greetings, Tobias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[api-dev] Re: Running OpenOffice hidden without xvfb

2006-05-16 Thread Ulrich Maurer

Hi Tobias,

Tobias Krais schrieb:

Is there really no other possibility than
installing xvfb?


Have you tried to use the -headless command line parameter when starting 
soffice?


Regards,
Ulrich.

--

## Gottesdienst der besonderen Art: http://kaiserslautern.feg.de

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] Re: Running OpenOffice hidden without xvfb

2006-05-16 Thread Tobias Krais
Hi Ulrich,

 Is there really no other possibility than
 installing xvfb?
 
 Have you tried to use the -headless command line parameter when starting
 soffice?

no, I bootstrap OO from my Java program.

Greetings, Tobias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] use of css.awt.UnoControlScrollBarModel

2006-05-16 Thread Paolo Mantovani
Hi Frank,

Alle 08:54, martedì 16 maggio 2006, Frank Schönheit - Sun Microsystems Germany 
ha scritto:
 Hi Paolo,

  In spite of this, reading the IDL description it seems that all should
  happen automatically, without listeners or event binding, infact:
 
  css.awt.UnoControlScrollBarModel
  ---
  boolean LiveScroll;
  Description
  specifies the scrolling behaviour of the control.
  true means, that when the user moves the slider in the scroll bar, the
  content of the window is updated immediately. false means, that the
  window is only updated after the user has released the mouse button.
  Since
  OpenOffice 2.0.0

 As I said elsewhere in the thread, the documentation is misleading here.
 In fact, the property controls how events are fired. Reactions on those
 events are up to the client code. 
 (You can use scrollbars for more than 
 for scrolling windows. For instance, you can bind them to spreadsheet
 cells :)

Yes yes!! but as you can see, I sent this post Sunday night, before to read 
your first answer.
Unfortunately the post was delivered only today. (I don't know why!)


 i would expect attach a dialog window or frame to it ?
 how would you
 implement both horizontal and vertical slides
 
  Perhaps this should e matter of an RFE
  Currently the css.awt.ScrollBarOrientation constant group offers only:
  HORIZONTAL and VERTICAL
  the BOTH option is missing.

 Hmm? How would you expect such a scrollbar to look like? How would you
 expect a user to operate it?

In effect the best would be to have a specialized scroll-panel beside the 
existing scrollbar control for general purposes.

For example in GAMBAS (a RAD for KDE that uses the QT toolkit - I love it ;-)
there is a ScrollBar control for general purposes that is very similar to 
UnoScrollBarControl, and, must be managed manually.

In addition, there is also a specialized control called Scrollview that is a 
panel where you can put other control as children.
The scrollview control manages automatically the position of its children
In order to manage the appearance of the scrollbars you can set the property 
ScrollBar that takes the following const values:
0 - None
1 - Horizontal
2 - Vertical
3 - Both


 In all widget programming I ever did, the model is more or less like
 this:

 +--+ +-+

 | (1)  | |^| (2)
 |
 |  | |v|

 +--+ +-+
 +--+

 ||   (3)||

 +--+

 A main window (1) which contains the to-be-scrolled content, a vertical
 scrollbar (2), and a hortizontal scrollbar (3) - all three having the
 same parent, instead of being children of each other.

Very intersting. IMHO there is a lack of examples/documentation/best 
practice/etc. reagarding AWT, so, thank you very much for information and for 
the nice ASCII illustration :-)


 There are toolkits which allow you to knit (2) and (3) with (1) so that
 scrolling happens automatically. But currently, AWT, OpenOffice.org's
 UNO-based toolkit, does not belong into this group.

Yes I see.
Anyway I think that it would be possible (and perhaps not so difficult) to 
make an UnoScrollViewControl that works like the one in GAMBAS.

At the end it's only matter to put some already existing components together 
and to add some glue code (I think).
Perhaps this could even be done in Python ?
Furthermore, If there would be a way to integrate new uno-controls in the 
DialogDesigner via uno-packages it would be really a nice challenge... :-)



  The hope would be that the developer that have implemented this thing is
  reading us.

 The LiveScroll property was implemented by me :)

So you won another big thank you for taking the time :-)



 Ciao
 Frank

ciao
Paolo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] Running OpenOffice hidden without xvfb

2006-05-16 Thread Carsten Driesner - Sun Germany - ham02 - Hamburg - Software Engineer

Tobias Krais wrote On 05/16/06 11:36,:

Hi ML,

I have one more problem with my OO document converter in java. It is now
finished and I am calling this little jar file in linux from the
commandline. My goal is to convert a document on a server without X.

With an X server / xvfb it works without problems. But without it always
says it wants to connect to X. Is there really no other possibility than
installing xvfb?
OpenOffice.org needs a X server, there is currently NO way to use it 
without one. The headless mode was designed to be used with a xvfb.


Why is X needed?
OpenOffice.org uses VCL as the GUI library which needs a working X 
server. Please ask the VCL guyes if you need more information on the 
dev@gsl.openoffice.org mailing list.


Regards,
Carsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] Easy to use complex toolbar controls for add-ons

2006-05-16 Thread Mathias Bauer
Laurent Godard wrote:

 Hi Carsten
 
 Just for your infomration. The new toolbar controller enhancements are
 not a com.sun.star.awt substitution. The implementation is deeply
 integrated into the Office framework and therefore cannot support the
 same feature set as low-level awt controls! Most functions are supported
 or can be added without any problem.
 
 thanks for your precision
 but this sounds odd to me regarding UNO nature and componentization
 
 I'll have a look (m169 just finished downloading) trying to understand
 how it actually works (with an external poor user pow)
 But i think that script coders are expecting to have access to the
 standard features and events of such controls and that's why i told
 about the awt controls

Carsten already explained why our concept is more abstract than the AWT.
But there is another reason why we don't expose concrete controls: we
don't want to lose the flexibility to change our UI. As an example, if
OOo would ever want to implement something like the new ribbon GUI
from the upcoming MS Office 12 we could do that without any changes in
the other code of OOo, just because there is no code anywhere in OOo
except in the LayoutManager that knows about the concrete build-up of
the UI elements. We only expose what we think belongs to the nature of
the dispatched commands, not how they are visualized. At the end that's
what the Dispatch API (and Carsten's new extensions) is about.

As an example, if your command is assigned to a list of element where
you can choose one and also have a status information about which one
was chosen for the current context the natural representation of this
fact is an element list, so there is an API to exchange list functions.
But we don't expose wether we represent this list as a list box or
something else so that we are free in our current and future(!)
implementations, we only expose the idea of a list being part of our
GUI. Think about it in the following way (I again take the example of an
element list):

Your code is assigned to one or more GUI elements that visualize a list
of elements (e.g. strings) and allow to choose one of them. OTOH these
elements expect from your code that it tells them which element should
be taken as the currently selected one (if possible). That's the
contract between your code and the GUI. How the elements look (if they
look at all - they could be implemented completely different, e.g. by
assistive technologies, as accoustic controls etc.) and where they are
located is not only unknown to you, it's completely irrelevant. I hope
you can see the benefit of this approach and that you don't loose
anything with it because all essential information is handled through
the abstract communication API(s) laid out by Carsten.

I for myself would have liked to have abstract assignments of commands
to types (like string list, integer value etc.) instead of
(button) control names, but Carsten preferred the control names instead
because it looks simpler and less techy. As it is his baby I think
that's okay, but OTOH it seems that it sets wrong expectations.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] Easy to use complex toolbar controls for add-ons

2006-05-16 Thread Mathias Bauer
Laurent Godard wrote:

 Hi Mathias
 
 Hm, listeners can be registered by another macro, that itself can by
 started by an event - and the listeners themselves are called by the
 event source. Or what do you mean?

 
 how is the first macro called ?

Event bindings, jobs ...

 regarding, the scope, as paolo sais, it seems to be possible that
 listeners are not unregistred when the macro ends
 i've never tested this way but this does not solve this specific problem
 (perharps using an array ?)

*If* listeners survive the macro termination at all I assume they
don't need a global variable; as long as they are registered somewhere
there is another object that should hold them alive. My apprehensions
have been that it's not a question of object life time but some basic
internal problems. We should check that. IMHO Basic listeners should
work until their UNO RefCount goes down to zero.

 As already mentioned: currently there is no way to pass an object to a
 macro that shall be called by macro URL or macro name. Problem number one.
 
 that's why i spoke about an intermediate that relay the call, adding the
 event
 Btw, do you mean inside the code or through xcu files ?

Inside the code. And a relay object doesn't really help here. At the
end there has to be an object that calls the macro by URL, e.g. by using
macro URL dispatching or Scripting Framework call and IIRC you can't
pass an object reference or anything else than strings either way. But
please see my last comment in this mail.

 If I understood correctly you want to create a listbox in the toolbar
 that depending on the selected entry calls different macros, right?
 
 no
 take the uno list objetc
 it has events, i want to have the same ones

That's what you wrote. But is it really what you need? ;-)
Without dynamic status updating and receiving all the events are pretty
useless. *If* you want to use them you need to think about ways to store
the data and perhaps update the UI elements on demand.

 Now let's discuss the way how the listbox gets filled. This is the point
 where the status updating comes into play: a dispatch object will
 initialize the listbox and also change its content. As already described
 this is the second problem I see that needs to be solved if we want to
 use all the new toolbar features in Basic.
 
 right, but teh same mechanism previously proposed can be used, no ?
 i tis a matter of event intializing

We face the same problems here: if you call a macro by name all you can
pass to it are string parameters. But again please see below.

 Your example seems to be simpler: I don't see that you want to change
 the content of the listbox at runtime, so having a static dropdown menu
 button that gets the macros to be called for each list entry by a
 configuration file (Addon.xcu) and not by status updating as described
 by Carsten would be enough. Why establishing a complex communication
 channel for something that is sent only once?
 
 argh, perharps my example was not so good explained
 obviously, i want to be able to manipulate the listbox dynamically !!
 fill it, remove items, retreive active item ...
 like a real componenent

OK, in this case you need the full program and this maybe can be done by
implementing the idea I described in my last mail. Perhaps we should
continue there.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] Easy to use complex toolbar controls for add-ons

2006-05-16 Thread Mathias Bauer
Laurent Godard wrote:

 The only problem then will be to identify the dispatch object amongst
 the bunch of them that might have been created, but as we can make frame
 and command URL accessible to the listener (implemented in Basic) we can
 use the combination of both as a unique identifier for searching for the
 dispatch object in a global container of such objects. I will draw up
 this in a more detailed manner.
 
 each toolbar objects has a name
 so a getByName like over a sequence could be a solution

Please forget the toolbars. ;-)
The command URL is the only thing that counts, in conjunction with a
frame reference. I hope I can make this clear in a more elaborated
description. I'm afraid I will not be able to provide it before the
weekend. I'm working on OOo programmability mostly as a volunteer
also. :-)

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [api-dev] use of css.awt.UnoControlScrollBarModel

2006-05-16 Thread Frank Schönheit - Sun Microsystems Ger many
Hi Paolo,

 In effect the best would be to have a specialized scroll-panel beside the 
 existing scrollbar control for general purposes.
 ...
 In addition, there is also a specialized control called Scrollview that is 
 a 
 panel where you can put other control as children.
 ...

Yes, most toolkits I know have some specialized Scrollable, the one or
the other way. Before AWT can get this, I suppose we need a real support
of nested windows. Currently, it is - AFAIK - possible to create them,
but it requires a lot of manual work, not to mention the missing
designer support.
Given than the ScrollableView is probably part of some container
window, and contains other windows itself, nesting is essential here,
/me thinks.

 Yes I see.
 Anyway I think that it would be possible (and perhaps not so difficult) to 
 make an UnoScrollViewControl that works like the one in GAMBAS.
 
 At the end it's only matter to put some already existing components together 
 and to add some glue code (I think).

Yes, probably.

 Perhaps this could even be done in Python ?

Again: Yes, probably :)

 Furthermore, If there would be a way to integrate new uno-controls in the 
 DialogDesigner via uno-packages it would be really a nice challenge... :-)

Submit an RFE :). This would be a really interesting ... (we plan this
for years for form controls, which share a lot of concepts and
implementations with dialog controls)

 So you won another big thank you for taking the time :-)

You're welcome :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[api-dev] Fwd: [webmasters] Link broken

2006-05-16 Thread Louis Suarez-Potts

FYI,
Louis

Begin forwarded message:


From: Patel, Kalpesh \(NIH/OD\) [C] [EMAIL PROTECTED]
Date: May 16, 2006 2:35:05 PM EDT (CA)
To: [EMAIL PROTECTED]
Subject: [webmasters] Link broken
Reply-To: [EMAIL PROTECTED]

I am trying to download the API manual via

http://api.openoffice.org/files/documents/22/3213/ 
OpenOffice.org2.0.2_AP

I_Reference_Manual.zip

It comes back with an error.





I appreciate if you can fix it (or let me know of new location).



Thanks



Kalpesh S. Patel
Contractor
eRA Architecture Team
Ekagra Software Technologies, Ltd.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]