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

List:       koffice-devel
Subject:    Re: OASIS file format for Krita
From:       Thomas Zander <zander () kde ! org>
Date:       2004-03-24 10:18:27
Message-ID: 200403241118.28318.zander () kde ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 March 2004 10:50, dirk.schoenberger@sz-online.de wrote:
> > Why? Because of the mental model that is needed? Because of the GUI
> > that gets in your way? If not, then what?
> > You do know that you can open the 'part' in a separate window as well;
> > making the seperation to another 'part' stand out better visually.
> >
> > In this mail, and the email you sent 10 seconds after this one you
> > fail to say why it is _wrong_ to have more features?
> > So far all I get from you is that you personally think users won't
> > need it.
> > I can tell you that that is not going to convince anyone; you will
> > have to do better then that.
> >
> > Please make me understand why you want this since I know from years of
> > usability experience that dumbing down a user interface has NEVER ever
> > helped to make the interface more usable. Developers always add new
> > features later anyway.
>
> Basically I have the following problems.
>
> - the load time and memory to bring up a full scale image editor like
> Krita (opposed to a simple image editor like KolourPaint). E.g. I don't
> like to wait until the image editor loads its complex plugin system (not
> sure about if Krita supports this yet, but I have seen other image
> editors, like the Corel products)

Agreed; loading should not be slow. Fortunately the base libraries are 
shared making the loading time to be specified purely by the part itself. 
(the koffice part that is).
Naturally the plugins should be lazily initialized and loaded.
You should be aware that Corel loaded its plugins as programs, not as dlls 
making the performance hit to be executed each time the app started (i.e. 
no caching was done).  It is my understanding that any and all plugins 
used in KDE are going to be shared libraries; taking away that performance 
hit.

> - the GUI doesn't match if you use Krita in "component" mode. Most GUI
> elements are implemented as tabs, and at least last time I checked,
> these tabs are shown in the component area, instead of merged with the
> container UI, e.g. via XMLGUI.

True; if its a koffice part; it should follow the koffice design. I'm 
pretty sure everyone agrees on this; but nobody spent time to change this 
yet. Have you spent time on that yet? Many people will thank you :)


> - the position and extents are handled by the part, istead of by the
> container.
> So basically you have a component of arbitrary size embedded in a parent
> page which needs only specified sub-document. This also includes visual
> representations like rulers. Components can also not span multiple pages
> in the parent document.

As David said elsewhere on this thread; these are things people are aware 
of. A better design has to be created by someone.
Do you know that koffice-parts is code that has been designed over 6 years 
ago already (from the top of my head..)  not much changes since; it could 
really do with an upgrade.

Thank you for answering these questions; I like it a lot better to fix the 
problems you and others find at the core level. It would probably go a 
long way towards taking away your hesitance on embedding components.

On the multi-page part in a KWord doc;
the concept of page-spread (where you have an even and an odd page facing 
each other which can be marked up as one page) has to be introduced one 
day to take away many problems, ones that is in place your multi-page 
question will probably answered.

Would you have time to program something like that?  If needed I and David 
could probably create a far-reaching design-draft that makes it a lot 
easier to implement already.
- -- 
Thomas Zander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYWBzCojCW6H2z/QRAqijAKCRTlkz7szP0pggJBtUBDdTjUMBpACgyzFG
JraROxzW9RWT+cR7uv4Yqls=
=pKTq
-----END PGP SIGNATURE-----
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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