[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Karbon & Krita 2Beta5 don't fit screen
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2007-11-21 20:02:48
Message-ID: 200711212102.48420.boud () valdyas ! org
[Download RAW message or body]

On Wednesday 21 November 2007, Thomas Zander wrote:

> Why is that relevant for tabbing?

It is not relevant for tabbing per se, but it is darned relevant for
making sure the default appearance of an application is the right one.
Whether the layer docker appears top right or bottom right is really
important. Loading the plugins and constructing the dockers in the order
of loading is not going to give consistent results from desktop to desktop,
from user to user.

> Are you doing all this to make sure a particular docker is shown by
> default? (aka the active tab) I would expect Qt to persist this info.  If
> it doesn't then thats a bug that warrents inspection.

The key word is "default" -- Qt persists the user's chosen configuration, 
which is great. However, barring an initial configuration, i.e. on first run,
the order of the tabs and which tab is shown initially is very important. 
That's what this code achieves.

In fact, since Qt persists the state the user closed the application in,
this whole discussion is only relevant for the "virgin" state of the 
application, i.e., on first run.

It's not just that I want a particular docker shown in the active tab by 
default, it also needs to be on the right row.

> Right, this is the core of the stuff.
> Naturally you are reproducing (and fighting!) a lot of code that is
> already in QMainWindow here for the plugins.

There is no code in QMainWindow, nor KoMainWindow, nor KoView that helps me 
with:

* the order the dockers are shown in on first run
* which tab is shown by default on first run
* ensure that no dockers from plugins are shown by default in places that I 
don't want on first run

> I'm not sure which problems you are facing and why you don't *just* have
> the above 3 calls, but I'm sure that if you explain that we can work
> together to make the koffice wide framework handle this more smoothly.

Because, if I don't have them the stroke docker plugin is created first, which 
means that the color, palette, stroke docker combo I want on the second row 
instead of on top, appears on top. 

It's just like layouting -- the widget you create first and add first to a 
layout is shown on top. This conflicts with hands-off creation of widgets by 
plugin loading singletons which makes by itself control over the layout 
impossible. It's the same problem we have with plugins that get a place in 
the menu through a .rc file -- but with dockers the issue is much more in 
your face. I've often thought that having kxmlgui govern the dockers would be 
a solution for the default-first-run placing and showing of the dockers, but 
I more and more doubt that, precisely because kxmlgui cannot order the menu 
entries either.

> Thanks for digging into this!

What I think would be grand is some way to describe the default layout of the 
dockers in the same way Qt restores the layout after changing it -- Qt knows
how to read that, and poof! all problems are solved. If we have that, it's 
going to be really easy, too, too add a menu option to restore the default 
layout. (Although I haven't tested re-running the code now in kisview2 after 
the view has been constructed, I guess removing all dockers, adding the right 
ones in the right order and then tabifying them works.)

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
____________________________________
koffice mailing list
koffice@kde.org
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]