Hello Carsten, *
[for some background info concerning what we're talking about, vid.:
http://www.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=2074518
http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancement]
Carsten Driesner escribió:
Hello Carsten,
I send you a first version of the extended menu api.
For clarifying some ideas to myself (and - lazy me - to save writing
the
same again and again) I wrote the following wiki page:
http://wiki.services.openoffice.org/wiki/User:Arielch/Menu_API_Enhancement
Take your time to evaluate this (I know you're busy, so don't need to
harry), in the meantime I'll keep working on it, as I left some things
undefined (because I don't have a clear concept about what's the best
decision to take), for example the matter of throwing eceptions I
implemented this only on XPopupMenuExtended, not in XMenuExtended2,
just
to see how it feels; and I only throw NoSuchElementExceptions (an
IllegalArg.Excep. didn't much sense to me, as I allow empty objects in
setter methods to use them to remove).
The XMenuBarExtended is now only a multiple inheritance to ease the use
of the API, but I've already implemented almost everything in vcl
MenuBar, but
Hi Ariel,
Sorry for the delay but I was very busy. Unfortunately OpenOffice.org
3 final is still not ready to be published. I have just finished the
review of your changes and want to give you some feedback.
* I'm not sure what has to be made available to API clients
I think it's mandatory that important features implemented by VCL
should be available via UNO AWT. It's too expensive to just take
every single method and make a one to one copy of VCL classes. In the
end UNO AWT is an abstraction layer above VCL to allow 3rd party
developers to create extensions and a way to replace a toolkit
without adapting other code. In the framework project we tried to use
UNO AWT most of the time to minimize the dependencies.
* AFAIK the floater and hide button don't have any functionality (at
least I didn't find any on vcl)
I am not sure what you mean with floater and hide button regarding
menus.
I attach a picture for you to see. The respective functions in VCL
Menu are
void ShowFloatButton( BOOL bShow = TRUE );
BOOL HasFloatButton() const { return mbFloatBtnVisible; }
void ShowHideButton( BOOL bShow = TRUE );
BOOL HasHideButton() const { return mbHideBtnVisible; }
void ShowButtons( BOOL bClose, BOOL bFloat, BOOL bHide );
void SetFloatButtonClickHdl( const Link& rLink );
const Link& GetFloatButtonClickHdl() const;
void SetHideButtonClickHdl( const Link& rLink );
const Link& GetHideButtonClickHdl() const;
as far as I could research, there is no code making use of them.
* there are some issues with the current menu bar implementation that
need to be solved beforehand; mainly, setting an UNO AWT MenuBar on a
top window crashes OOo. I've discovered that the "issue" in the SDK GUI
example
http://api.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19085
is in fact a MenuBar issue: nor VCLXMenu nor VCLXTopWindow
(VCLXTopWindow_Base keeps in a protected member a reference to the
XMenuBar set in setMenuBar, but nothing is done) take care of
destroying
the menu bar window, so when the top window gets destroyed, vcl
complains about its liven child.
How to reproduce this, and where OOo crashes, depends on the build
(product / non-product), I attach a Writer doc for you to try (a
product
build I execute the macro from the IDE, then close the doc. and OOo
crashes), and the gdb trace. On a non-product build is easy to follow
the stack: basically VCLXWindow::dispose checkes if the Window is still
alive (GetWindow()); if so, DestroyOutputDevice() starts the process of
destroying it. All ends up with the menubar window being still alive,
and in a non-product build window.cxx 1.285 4456 informs us about the
live window.
Playing with this I've found that the crash can be avoid from the
client
code by setting a null XMenuBar on the top window *before* invoking
XComponent::dispose on the XWindow: VCLXTopWindow_Base::setMenuBar will
always invoke (before even testing if the reference is empty)
SystemWindow::SetMenuBar with a NULL arg., and this makes SystemWindow
ensure that MenuBar::ImplDestroy is called to destroy the menu bar
(vcl/source/window/syswin.cxx 1.54 904 ss)
It seems that this is the way to follow to destroy the menu bar: the
LayoutManager does so in LayoutManager::impl_clearUpMenuBar
(framework/source/layoutmanager/layoutmanager.cxx ... blah! don't need
to quote, as you are the Master here!).
I'm not sure what the way is to follow in order to solve this issue:
should VCLXWndow keep track if it has an Uno AWT XMenuBar, lets say
by a
private member sal_Bool mbHasAWTMenuBar that can be set by derived
classes with a protected SetAWTMenuBar(sal_Bool bHas), and before
invoking VCLXDevice::DestroyOutputDevice, invoke
SystemWindow::SetMenuBar (NULL) if mbHasAWTMenuBar?
I'm not sure if this is plausible, any way not directly from
VCLXTopWindow_Base as it is not derived from VCLXWindow. As you've
seen,
I've been studying...but not that much, so don't take this
seriously: it's too late at night and I might be saying nonsenses.
I want to talk to Philipp Lohmann, the gsl project lead, what he
thinks would be the best way to solve this issue.
Well, that's all for now, I'll go to sleep. I'll wait for your
comments on the "extended menu api" (again: I'm aware your too busy,
so don't need to hurry :-) )
There are some comments in the interface definition which refer to
OpenOffice.org.
E.g. see setItemImage(...) defined in XPopupMenuExtended.idl
<p>The image will be displayed regardless of the current configuration (
<code>/org.openoffice.Office.Common/View/Menu/ShowIconsInMenues</code>).</p>
if <TRUE/>, the image will be scaled to the standard size used
internally by OpenOffice.org for menu items.
Interfaces are normally a set of methods which have a special
purpose. The interface should not be restricted to any implementation
but be as generic as possible. I see your point that some information
are very helpful for developers who want to use an interface in the
OpenOffice.org context. If this kind of information is put aside it's
possible that developers won't find it. I will try to clarify this
conflict with Juergen Schmidt.
One method in the XMenuExtended2 interface is defined as:
boolean hasValidEntries( [in] boolean bCheckPopups );
and the comment of this method states: "checks whether the menu has
valid (enabled) entries." You introduce a new state called "valid"
which you describe in brackets as enabled. From my point of view it
would be better to use the word in brackets for the method: boolean
hasEnabledEntries(...). The state enable is known due to the fact
that there are methods to enale/disable menu items. I think you don't
need to invent a new state (valid) and describe it. As far as I can
see the method just returns if the menu and possible children have at
least one enabled entry. Therefore the best solution would be to just
use "enabled" instead of "valid".
You're right, I'll correct this. But I'm not so sure if this method is
really useful: it returns true as far as the menu has at least one item,
it is not a separator, and it is enabled; client code could easily
design - using the Menu API - its own algorithm to check this. So what
do you think, do I keep it?
A same question goes for XMenuExtended2.isMenuBar and
XMenuExtended2.isPopupMenu; I think they are useful when one works in a
generic algorithm that can take both a PopupMenu or a MenuBar as
argument, but are they both to be included, or only one? (if isMenuBar()
returns false, I know it's a PopupMenu, so there is no need for
isPopupMenu(); the same vice versa )
Hi Ariel,
In the end you are right that not quantity but quality counts. That
means that the interfaces should be as simple as possible and as complex
as needed. Extended methods which could be implemented by other methods
should be the exception.
with the same spirit, I think I could remove all the hasXxx and
removeXxx in css.awt.XPopupMenuExtended (I've implemented them so that
the same can be done by client code with the getter and setter methods)
[an exception is the css.awt.MenuLogo, where - depending on the impl.
language - setMenuLogo(NULL) may not remove the MenuLogo, but draw a
vertical black line; anyway I can correct this]
The buttons in the menu are currently an
implementation detail of VCL to support a special mode in
OpenOffice.org, e.g. the last document window can be closed and the
start center screen comes up. I don't think that we have to support this
feature in UNO AWT.
I think I wasn't clear. There are three buttons (plus custom ones, as
the one added by the update feature):
* the closer
http://www.ArielConstenlaHaile.com.ar/ooo/MenuAPI/XMenuBar_CLOSER.png
* the float button
http://www.ArielConstenlaHaile.com.ar/ooo/MenuAPI/XMenuBar_FLOAT_BTN.png
* the hidde button
http://www.ArielConstenlaHaile.com.ar/ooo/MenuAPI/XMenuBar_HIDE_BTN.png
Concerning the menubar closer, I imagine some use cases where API
clients may want to manipulate it.
One existing use case:
http://api.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=19395
I quote:
1. It's possible to get rid of the desktop close button (the small "X"
in the top-right) when there is only one opened document (when the
document is opened by my app)?
Another case is client code that wants to create its own windows and
frames without adding these last ones to the desktop frames hierarchy:
in this case, the application framework will never show the closer on
the last and only frame on the desktop.
I have some other questions, concerning this and other related topics,
should I send it to you, or to the API mailing list? (I ask, because
I've really learn a lot from discussion made publicly in [EMAIL PROTECTED] and
other mailing list, so this could be interesting for someone).
Yes, please go on and ask your questions on the API mailing list. I
think it's a good idea to have a a bigger audience with new ideas and
opinions.
Regards
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
http://www.ArielConstenlaHaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
