One thing that we may wish to look into is using the same concept as the
Chromium project does - pulling colors in from the user's native desktop
environment, but not necessarily using those widgets.  This will give
LibreOffice the ability to render its own layout and even graphics options,
but it will render them in a manner that allows for much better desktop
integration without completely rejecting using our own layout/widget
concepts...

Yours Truly,
Scott Pledger


On Wed, Apr 27, 2011 at 16:01, RGB ES <rgb.m...@gmail.com> wrote:

> 2011/4/27 Christoph Noack <christ...@dogmatux.com>:
> > Hi Scott!
> >
> > You asked a tough question ... something we struggled quite some time
> > within OpenOffice.org. So the question is not _if_ we apply platform
> > specific elements ... the question is rather what we can share accross
> > all platforms, because there is no reference implementation.
> >
> > Some examples:
> >      * Toolbar color-picker
> >      * New "Slide layout" drop-downs
> >      * Slide sorter in Impress
> >      * Print dialog (on some platforms, there is no reference
> >        implementation)
> >
> > To me, this should be something that should be agreed on ... with the
> > development and marketing to define a "degree of freedom".
> >
> > It's already part of the WhatWeNeed list, I've mentioned earlier ...
> > Collect, clarify and document fundamental questions [...]:
> >        "Platform specific" (respect the platform interaction
> >        guidelines ... e.g. like Mozilla Firefox) vs. "Platform
> >        independence" (work the same way on any platform ... e.g. like
> >        web sites)
> >
> > Is this what you had in mind? Would you be interested in driving this
> > effort (the item "Clarify Marketing Questions")?
> >
> http://wiki.documentfoundation.org/Design/Kick-Off/WhatWeNeed#Knowledge_and_Requirements
> >
> > Am Mittwoch, den 27.04.2011, 10:49 -0600 schrieb Scott Pledger:
> >> My only concern when asking this question is the implementation of any
> kind
> >> of a graphical look and feel - layouts would be the same across
> platforms,
> >> but should the look and feel (things such as the coloring/graphics of
> the
> >> application) apply the user's system theme or whether the coloring and
> >> graphical feel of LibreOffice should be the same across all platforms in
> >> addition to the layout or if the layout should merely implement the
> user's
> >> native look and allow the system to apply whatever its theme is.
> >
> > Just one addition - I usually refer to "look" as the visual style, and
> > "feel" as the behavior which also includes the workflows of the
> > software.
> >
> >> Yours Truly,
> >> Scott R. Pledger
> >
> > By the way, although we don't get any statistical evidence for users, I
> > really like these small surveys ... thanks!
> >
> > Cheers,
> > Christoph
> >
> >> On Wed, Apr 27, 2011 at 06:53, Daniel Merker <daniel.mer...@wayne.edu
> >wrote:
> >>
> >> >
> >> > 2011/4/26 Scott Pledger <scottpledger2...@gmail.com>:
> >> > > Purely out of curiosity, how many people here prefer that the user's
> >> > > default environment theme (GTK, Qt, etc.) be applied to LibreOffice
> >> > > versus how many would rather see LibreOffice get its own look
> >> > > independent of the desktop environment?
> >> >
> >> > >From a Core UI stance, LibO should have a consistent look across all
> >> > platforms; for example, where the toolbar is, what is under each menu,
> how
> >> > use cases are performed. The outer shell should conform to the
> standard of
> >> > the platform; for example, where the max/min/close buttons are, what
> order
> >> > those buttons should appear. IMHO, when you try to please everyone
> with
> >> > different versions, in this case based on platforms, of a UI, you tend
> to
> >> > please no one....
> >
> >
> >
> > --
> > Unsubscribe instructions: E-mail to design+h...@libreoffice.org
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/www/design/
> > All messages sent to this list will be publicly archived and cannot be
> deleted
> >
>
> I think there are two points to consider, with a bit of "grey scale" in
> between.
> On one hand, functionality. On the other hand, aspect.
>
> Functionality is about how the software works, and here we have some
> freedom: we cannot compare a word processor with a web browser, so if
> a KDE user navigate the web with konqueror but write their documents
> with Writer, the fact that both programs behave different will not be
> a problem. Printer dialogue is different? OK, as far as it works, no
> problem...
>
> Then, the aspect: if you will be eight hours in front of the screen,
> at least you want to look at something that it is "nice". From this
> point of view, LibO picking the widget colours and icons from your DE
> is something good.
> (At this point something to consider is LibO using the freedesktop
> standars on icon naming so it can use as much as possible the icons
> from the DE... no idea if this is feasible, I'm just thinking aloud)
>
> Then, you have the grey scale: for example, the LibO's native file
> picker is just terrible, not only because ugly but mainly because it
> do not gives you the possibility to set bookmarks. In that case, the
> possibility to use the DE file picker is something good too.
>
> But here we arrives to a problem: openSUSE and other distros (I just
> read about chackra compiling LibO without a single GTK bit) delivers a
> LibO version that enables the kde4 plugin for the vcl system used by
> LibO to draw the interface. So, with openSUSE's LibO you have the kde4
> file picker... at the cost of a really bad visual integration: the
> plugin (which is not compiled for the "official" LibO version) is not
> quite ready yet and have problems like excessive repainting, random
> performance lost, etcetera.
> If you delete that kde4 plugin LibO will use the GTK one instead, and
> GTK apps looks perfectly on KDE4 if you use an appropriate widget set
> like qtcurve.
>
> So? I dunno, as Christoph said this is a tough question.
>
> Cheers
> Ricardo
>
> --
> Unsubscribe instructions: E-mail to design+h...@libreoffice.org
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/www/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

-- 
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/design/
All messages sent to this list will be publicly archived and cannot be deleted

Reply via email to