KDE4 Development Critical Path

[Jaroslaw Staniek]

Hamish Rodda said the following, On 2006-03-14 11:51:

> On Tuesday 14 March 2006 21:41, Aaron J. Seigo wrote:
> 
>>On Tuesday 14 March 2006 03:07, Thiago Macieira wrote:
>>
>>>Please elaborate on what needs to be done for KParts and KXMLGUI.
>>
>>hamish rodda, post-kaction branch merging (does that belong on the chart?),
>>is apparently looking into changing xmlgui fairly radically. it was
>>discussed a couple months ago on the list, and he mentioned it again in the
>>thread titled "Consideration requested for merging of kdelibs-action
>>branch":
>>
>>quoting him there:
>>
>>"This branch does not alter XMLGui in any way other than direct porting.
>> I've had several people express their concern re. moving to another
>>system, and I'd like to keep that as a separate discussion."
> 
> 
> Actually it's Simon Hausmann that initially suggested replacing XMLGui.  I was 
> supportive of the concept but I'd like to hear more detail on it first - 
> there are some things which could be improved by making a change (eg. 
> allowing people to design kde kaction-based apps using designer) but I'd be 
> hesitant to support change for its own sake (and I know there are several 
> people out there who definitely want xmlgui to stay).

my 2c:

What I needed within XMLGui (and implemented by deeply hacking it) is 
mentioned here:
http://www.kexi-project.org/wiki/wikiview/index.php?KexiComponentsForReuse#Shared_Actions

Proposal for "Shared Actions" is added to http://wiki.kde.org/KDE+4+Goals 
although I am aware many of you can live with current XMLGui behaviour, 
there're use where that we have problems especially with apps like Kexi or 
KDevelop.

There are questions in this department:
- when we introduce "shared" behaviour to actions we have to care about 
current "context"
- at GUI level, toolbars could be better managed and better behave (how this 
can interact with new Qt4 Main Window framework?)
- toolbars configuration dialog needs to better support shared actions (not 
all toolbars are visible or even loaded but all should be "declared" as 
available so user wants to see all of them available for configuration)
- are volatile actions (dissappearing menu/toolbar items) good for our HIG?
- (maybe) let's escape from "many and toolbars only at top level" e-facto 
guideline, and introduce small toolbars within child windows if needed 
(currently: within tabs/panes as Childframe iface is dead). E.g. I am using a 
mini toolbar within the Project Navigator: 
http://kexi-project.org/pics/1.0/python_scripts.png ; same for KDevelop/Kate
- how well can this play with KParts/KoParts?

What can I say? I'll be forced to experiment.

Note: Even while MS Ribbon[tm] (http://www.kdedevelopers.org/node/1617) better 
than our current tollbars, I am not asking for implementing it. However I 
believe we need an action framework for apps with complex action system, to 
decrease clutter. A lack of such framework can sometimes lead again to stuff 
reimplemented at applications level.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

Sponsored by OpenOffice Polska to work on
* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi
* KDE3 & KDE4 Libraries For Developing MS Windows Applications:
                   http://www.kdelibs.com/wiki
See also:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support:        http://www.kexi-project.org/support.html