[OT?] Re: KAction changes

[Jaroslaw Staniek]

Simon Hausmann said the following, On 2006-12-04 00:29:

> So we could like to merge those changes back into trunk, hopefully soon (maybe 
> tomorrow evening?). The changes don't mean that KAction goes away (at least 
> not directly), it merely makes our public API more consistent with Qt and 
> more compatible as well.
> 
> Does anybody have any additional input, objections or thoughts on this?

Additional input?
Just FYI and RFC - KAction/KXMGUI-related thing: how are we going to avoid 
problems like this [1] when there're empty toolbars? Two or more empty 
toolbars make the GUI's look unprofessional. This is more a question about 
view-based GUIs, i.e. the case when you have action A having multiple contexts 
(e.g. tabs can present entiely different type of content). For some tabs, A 
can be enabled, for some A is always disabled. Let's say A is "print" action, 
and you'll get the idea. Possible users of the view-based GUI are Kexi, Quanta 
and KDevelop.

In Kexi I have an action proxy where I can define that a given view accepts a 
given action, by declaring its by name (there can be even subviews of a view) 
that. For example, "edit_copy" action has many contexts, depending whether 
you've just focused a text edit widget or you're in a spreadsheet-like widget.

Long time ago dfaure gave me advice about a hack for KDE3 about hiding empty 
toolbars, but for KDE4 we could get a cleaner solution.
Other solution could be to move specific actions into a given tab as a private 
toolbar, somewhat on macosx - so we'll get actions with the same name on 
plugged on more than one tab, but then we'll need no proxies.

[1] http://kexi-project.org/pics/0.9/data_form_navigator.png

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org