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

List:       koffice-devel
Subject:    Re: Review Request: Improve the toolbox layout
From:       Thomas Zander <zander () kde ! org>
Date:       2009-07-18 9:05:32
Message-ID: 200907181205.33708.zander () kde ! org
[Download RAW message or body]

Hey Thorsten :)

First, 

These suggestions you replied to are not specific to KPresenter, they are 
meant to extend the concepts of flake and meant to extend in a cross-
application and consistent way the experience of how to manage tools and 
dockers.
KPresenter is just used as an example, please don't take any of this 
personally, its not :)

On Saturday 18. July 2009 07.00.04 Thorsten Zachmann wrote:
> > my memory of the discussion some months ago was that we could fix the
> > toolbox very easily (2 lines fix) but the ideal is not to fix that but
> > figure out why the different apps come up with different solutions for
> > similar problems and ending up, well, working against each other.
>
> If it is so easily fixed why are you so resistant in fixing it.

The toolbox as it is now has been written in 2005 for Karbon and (later) 
Krita with a design in mind of sections. In 2008 or so I rewrote it for Qt4 
kept that design and extended it.
Any 'fix' in the toolbox would either allow a section to be huge or even 
infinitely long. Thats not really a fix as KPresenter will *still* have a bad 
looking toolbox afterwards.
So, I don't think its fair to say I'm resistant to fixing it, I am not. I 
just want the fix to be in line with what Krita has been doing for years 
(with more tools, so KPresenter should be able to do so too) and what fits in 
the design of the toolbox.

> Only that
> there is an agreement that a lot of tools should be avoided does not mean
> the tool box should break when there are more tools. It is very easy for
> a plugin developer to add new tools. That should not break the existing
> applications. So lets fix the toolbox.
>
> > So,
> > yes, the current situation is not very useful and needs resolving.
> > Changing the layout of the toolbox is going in the wrong direction,
> > though. We would end up with even less coherence in design and less
> > consistency between apps.
>
> Sorry but that sounds like you are against fixing the toolbox.

I'm slightly annoyed you keep insisting we should just remove features from 
the toolbox that I added and you mark it as a 'fix'.
Can we please stay constructive?

> > So, as KPresenter shows very well the simple design we made 2 years ago
> > for flake needs some tweaking.
> > The problems KPresenter has can be solved in various ways and I think
> > we should all try to be creative and show suggestions. The current
> > solutions in KPresenter and the patch for the toolbox are sub-optimal.
> > I'd like to avoid throwing away features in the toolbox as I mentioned.
> > It feels we are working against each other. I'd love all the noses to
> > point in the same direction.
> >
> > Here are some suggestions from my side. Please comment, implement,
> > extend. Anything that stays constructive.
> >
> > * We can merge some tools. I don't think anyone disagrees, but it needs
> > to be done. Any volunteers?
> >
> > * We need less dockers.
> > My latest thought is one "Shape Properties" docker that takes plugins
> > (tabs) and shows all the different properties as tabs.
> > See here a very very quick mockup of such a docker. (one pic per tab)
> > http://yfrog.com/17shapeproperties1p
> > http://yfrog.com/2qshapeproperties2cp
> > http://yfrog.com/57shapeproperties3p
> > http://yfrog.com/5ishapeproperties4p
>
> I don't like this.
>
> The dockers Stroke Properties and Styles are also useful when no shape is
> selected. 

I agree, I detect a slight misunderstanding ;) this docker would always be 
visible. So that is not a reason to dislike it.

Was that the only reason you don't like my suggestion? (well, apart from the 
horrid icons ;) Then do you think its ok now since I cleared up that 
misunderstanding?

> > * We could rename the KoToolFactory::setToolType() for some kpresenter
> > tools so they are grouped more logically together instead of all in the
> > default section.
>
> There is only one kpresenter specific tool.

As I wrote above, this suggestion is not specifically about KPresenter. I 
think cyrille put forward several good suggestions for this point.

> Putting one tool into a
> specific section does not feel right for me.

That I certainly agree with.

> > * We should investigate splitting the default section of the toolbox so
> > there are tools that work without any selected shape and we have
> > different tools that work when at least one shape is selected.
> > On top of that, we might want to add a boolean in the shapeFactory to
> > notify that a shape has a background (a krita image or a pictureShape
> > don't for instance). This would mean that tools that manipulate the
> > background won't be shown if such a shape is selected. I'm thinking
> > about the gradient tool, for instance.
>
> When working on something like that please keep in mind that for
> kopageapp the gradient tool/pattern tool will be useful for modifying the
> background which is not in the shape manager.

This is also one of these inconsistencies between applications that makes 
the usage (and code) a bit harder. Please consider how to be more common and 
similar to the other apps.
If Krita manages to make each of its layers into a flake shape, KoPA should 
be able to add its background to the shapeManager ;)
Think about it!

<dream>all noses pointing in the same direction </dream>
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]