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

List:       koffice-devel
Subject:    Re: GSoC: KWord interface revamp proposal
From:       David Antler <david.antler () gmail ! com>
Date:       2009-03-23 22:34:47
Message-ID: 200903231734.47289.David.Antler () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Monday 23 March 2009 3:44:21 pm Thomas Zander wrote:
> On Monday 23. March 2009 18.58.43 David Antler wrote:
> > I still think that this is a logical progression from the current "Beta"
> > interface and would be a great benefit to the user
> For GSoC the proposals that I shall put my backing to are things that are
> not extending the core or touching code on a dozen dockers etc.  I would
> back proposals that use the KOffice plugin structure to add functionality
> and options.  I've said that before, and I'll say it again. We made KOffice
> extend- able for a reason, its a great thing for beginner developers and
> for enhancing all KOffice applications while shielding developers from the
> hard parts.

I understand why it must be hard to move to a new interface, and am glad 
there is recognition of need for some updates; whether it be a new default 
layout or a complete redesign.  It's a shame to see such useful software 
hindered by an undercooked interface.

My original idea was to just add new KWDockers to KWord's source, on top of 
the other ones, and to worry about old inheritances later.  I still think it's 
a good idea; it uses what's already built in to KOLibs to solve its usability 
problems.  

Perhaps toning down the ambition of the GSoC and instead creating a set of 
dockers to simply replace the toolbars is a more feasable project.  Is it 
acceptable to create a set of dockers through the use of plugins or 
extensions?  I'm not sure exactly what is possible while writing a plugin, but 
if I can more efficiently implement the toolbar's features in a way similar to 
my mockup, that would give users the option to move things around and 
maximize screen real estate using some of the ideas in my mockup.

Does this seem more reasonable?

[Attachment #5 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'Sans Serif'; font-size:10pt; \
font-weight:400; font-style:normal;">On Monday 23 March 2009 3:44:21 pm Thomas Zander \
wrote:<br> &gt; On Monday 23. March 2009 18.58.43 David Antler wrote:<br>
&gt; &gt; I still think that this is a logical progression from the current \
"Beta"<br> &gt; &gt; interface and would be a great benefit to the user<br>
&gt; For GSoC the proposals that I shall put my backing to are things that are<br>
&gt; not extending the core or touching code on a dozen dockers etc.  I would<br>
&gt; back proposals that use the KOffice plugin structure to add functionality<br>
&gt; and options.  I've said that before, and I'll say it again. We made KOffice<br>
&gt; extend- able for a reason, its a great thing for beginner developers and<br>
&gt; for enhancing all KOffice applications while shielding developers from the<br>
&gt; hard parts.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>I understand why it must be hard to move to a new \
interface, and am glad there is recognition of need for some updates; whether it be a \
new default layout or a complete redesign.  It's a shame to see such useful software \
hindered by an undercooked interface.<br> <p style="-qt-paragraph-type:empty; \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>My original idea was \
to just add new KWDockers to KWord's source, on top of the other ones, and to worry \
about old inheritances later.  I still think it's a good idea; it uses what's already \
built in to KOLibs to solve its usability problems.  <br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>Perhaps toning down the ambition of the GSoC and instead \
creating a set of dockers to simply replace the toolbars is a more feasable project.  \
Is it acceptable to create a set of dockers through the use of plugins or extensions? \
I'm not sure exactly what is possible while writing a plugin, but if I can more \
efficiently implement the toolbar's features in a way similar to my mockup, that \
would give users the option to move things around and maximize screen real estate \
using some of the ideas in my mockup.<br> <p style="-qt-paragraph-type:empty; \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Does this seem more \
reasonable?</p></body></html>



_______________________________________________
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] 

Configure | About | News | Add a list | Sponsored by KoreLogic