sven.langkamp at gmail.com
Mon Jul 6 23:10:53 CEST 2009
On Mon, Jul 6, 2009 at 8:12 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Monday 06 July 2009, Sven Langkamp wrote:
> >>>From what I can see the following features/bugs are left:
> > -preset chooser/collection
> > I'm not sure how Boud had envisioned it. At the moment there is the
> > combobox that only show "default" and the preset collection. Both do more
> > or less nothing at moment.
> Weird... the preset collection tab now shows patterns!
Yes, I currently have hard-coded the pattern resource server in the chooser.
But ok, I thought I had written down this before:
> * the second combobox and the preset collection will show exactly the same
> thing: all saved and pre-installed paintop presets for a particular brush
> engine. Those presets can be selected using either widget, but the
> tab will allow adding/removing presets. (Just as with other resources, like
Maybe use the resource selector combobox that is already used by the flake
pattern and gradient tools. It could show a preview of the current preset
and have a list of available presets.
> What is missing here is the implementation of the save button in the
> Preset Definition" tab. (the label in that tab should also contain a live
> preview of the preset with the current settings, like the one in the
> > How should they work and do we need both? For the delegate a preview of
> > paintop is needed. I guess it should look similar to the current brush
> > preview.
> We really need to be precise here, otherwise we'll get confused ourselves.
> brush preview (for instance in the brush selection tab in the "current
> definition" pane) isn't suitable, and the preset preview in the toolbar may
> not be suitable either, because it needs a fairly6 large space. I was
> of doing it similar to photoshop, and have the preset collection tab show
> either a single paintAt() preview in an icon view, or a listview of stroke
> previews with the name.
Yeah, I meant the preset preview. It currently has the problem that lots of
brushes can't show a useful preview.
Some brushes aren't suitable especially the bigger ones and paintops like
deform are totally different. We will probably need special cases for some
of the more special paintops.
Maybe the artists can make some mockups how each paintop should look like? I
think this is the most tricky part.
> > -settings widgets need to be per view
> > https://bugs.kde.org/show_bug.cgi?id=174356
> I'm fine with postponing that to the next release, if the saving/loading
> selecting of presets gets in for 2.1. It sucks, but it is also quite a big
> > -nested boxes in the settings
> > The settings widgets get a bit overstructured. Here are for example
> > three tabwidgets: http://img41.imageshack.us/img41/8729/paintopbox.png
> > We should try to reduce the amount of borders.
> I cannot take a look at that now, I'm on the train. But in general, I'm not
> concerned about over structured settings widgets for paintop presets yet --
> it's nothing compared to any other paint app yet :-)
Have a look. The design of other apps is no excuse ;)
> > Is there currently someone working on these issues? Boud? If not I will
> > these on my feature plan. Unfortunately all my exams will be prior to the
> > hard-freeze, so I don't know how much I can get done.
> > Of course code from any private git branch is welcome ;)
> I've been working on performance mostly, and some koffice library work.
> some work on making filters multithreaded again, and looking into all the
> regressions in our unittests) I haven't touched the preset
> code for quite some time, and I would love some help getting the
> loading/saving of presets as resources working.
> Boudewijn Rempt | http://www.valdyas.org
> kimageshop mailing list
> kimageshop at kde.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop