[scribus-dev] should Properties be drawn and quartered?
Louis Desjardins
louis.desjardins at gmail.com
Wed Jun 27 03:35:29 UTC 2012
2012/6/26 Gregory Pittman <gpittman at iglou.com>
> On 06/26/2012 08:53 PM, Louis Desjardins wrote:
>
> 2012/6/26 Gregory Pittman <gpittman at iglou.com>
>
>> It's an idea which occurred to me as I was making a text frame that I
>> intended to create columns in.
>>
>> What if we had an item in the context menu that said, for example, "Text
>> Tab", so that if you selected it, up popped a free-floating equivalent to
>> the Text tab of Properties, with all its settings, and it would stay open
>> until I closed it? If I selected a different text frame, its settings
>> applied there.
>> Similarly, I could bring up a Shape tab by right-clicking a polygon or
>> shape, an Image tab if I right-clicked an image frame.
>>
>> This is just some free-form musing about the mess that Properties has
>> become.
>> Perhaps the best way to conquer Properties is to draw and quarter it...
>>
>
> :-)
>
> I believe that this is where we are trying to go now. The PP would
> contextually offer the user the settings that are relevant to the active
> object. When in a Text frame, text settings, when in an image frame, image
> settings. Not even the need for a right-click.
>
> Ale could elaborate on this.
>
>
> But the point is, there are tabs which are context-specific and those
> which are not. I can imagine working with a text frame, having a
> free-floating text tab, and yet in the remnants of Properties working with
> XYZ tab functions. You would leave in Properties those features which might
> apply to various objects.
>
Yes, that’s the point. The PP lets you act on what you’re on. So, there
would still be a bit of redundancy in the PP but each pane you see has it
all for what you’re at.
Louis
>
> Greg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120626/143b3459/attachment.html>
More information about the scribus-dev
mailing list