From gmax@nightshade.z.ml.org Thu May 11 23:51:21 2000
Received: (qmail 21825 invoked from network); 26 Jan 1998 13:31:04 -0000
Received: from athena.nuclecu.unam.mx (132.248.29.9)
by mail2.redhat.com with SMTP; 26 Jan 1998 13:31:04 -0000
Received: from nightshade.z.ml.org (gmax@[206.124.79.5])
by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id HAA16948
for <gnome@nuclecu.unam.mx>; Mon, 26 Jan 1998 07:30:14 -0600
Received: from localhost (gmax@localhost)
by nightshade.z.ml.org (8.8.3/8.8.4) with SMTP
id IAA10011 for <gnome@nuclecu.unam.mx>; Mon, 26 Jan 1998 08:31:03 -0500
Date: Mon, 26 Jan 1998 08:31:03 -0500 (EST)
From: Gregory Maxwell <gmax@nightshade.z.ml.org>
To: gnome@nuclecu.unam.mx
Subject: Scroll bars.
Message-ID: <Pine.LNX.3.95.980126082447.9952A-100000@nightshade.z.ml.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Please, dont doom yet another interface with the same old stupid
scrollbars used in almost ever GUI out there.
They are inneficent and inconvient!
Normally scroll bars are placed on the right side, with little up and down
arrows on the top and bottom...
This is silly.. The mouse is more often on the left (it's where the menus
are and where text starts).. Also, going down then back up requires alot
of mouse movement..
It would be MUCH more sane to place them on the left and put the up and
down (and perhaps a page up and down) button all togeather on the top or
bottom..
I've tried chatting with someone with KDE a long time back... But he was
close minded.. Saying that it was too diffent from other GUIs
GNOME is diffent from windows, if you are going to make something
differnt, then do it right.. If people are goning to have to relearn
anything then it wont be alot to ask for them to get used to the differnt
scroll bars..
From nelson@crynwr.com
Received: (qmail 17879 invoked from network); 26 Jan 1998 14:13:37 -0000
Received: from athena.nuclecu.unam.mx (132.248.29.9)
by mail2.redhat.com with SMTP; 26 Jan 1998 14:13:37 -0000
Received: from ns.crynwr.com (ns.crynwr.com [192.203.178.14])
by athena.nuclecu.unam.mx (8.8.7/8.8.7) with SMTP id IAA17343
for <gnome@nuclecu.unam.mx>; Mon, 26 Jan 1998 08:12:46 -0600
Received: (qmail 20924 invoked by uid 0); 26 Jan 1998 14:13:59 -0000
Received: from desk.crynwr.com (128.153.44.67)
by ns.crynwr.com with SMTP; 26 Jan 1998 14:13:59 -0000
Received: (qmail 11543 invoked by uid 501); 26 Jan 1998 14:13:58 -0000
Date: 26 Jan 1998 14:13:58 -0000
Message-ID: <19980126141358.11542.qmail@desk.crynwr.com>
From: Russell Nelson <nelson@crynwr.com>
To: gnome@nuclecu.unam.mx
Subject: Re: Scroll bars.
In-Reply-To: <Pine.LNX.3.95.980126082447.9952A-100000@nightshade.z.ml.org>
References: <Pine.LNX.3.95.980126082447.9952A-100000@nightshade.z.ml.org>
Gregory Maxwell writes:
> It would be MUCH more sane to place them on the left and put the up and
> down (and perhaps a page up and down) button all togeather on the top or
> bottom..
Okay, everyone stand up and chant along with me and raster: "Themes,
themes, themes, themes....".
I was bitching to someone about how every X program has a different
graphical luser interface (GLI -- pronounced "glee", with glee). He
said "well, that's a good thing, because it's by no means obvious that
one GLI is better than another." Well, he's probably right, but
neither should EVERY program be different. Much better for every
program to access Generalized [Network] Objects (sound familiar?), and
let people customize ALL their programs at the same time. So if
someone decides that they want clustered scrollbar buttons with
shapes, they'll get this in the upper left-hand corner of ALL their
scrollable windows:
+------------------------------------
| | |
| ^ | v |
| | |
|------+-----+
| |
| |
| |
| |
|------|
|WWWWWW|
|WWWWWW|
|WWWWWW|
|------|
| |
| |
| |
--
-russ <nelson@crynwr.com> http://web.crynwr.com/~nelson
Crynwr Software supports freed software | PGPok | Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.
From raster@redhat.com
Received: (qmail 25659 invoked from network); 26 Jan 1998 14:19:38 -0000
Received: from athena.nuclecu.unam.mx (132.248.29.9)
by mail2.redhat.com with SMTP; 26 Jan 1998 14:19:38 -0000
Received: from trode.redhat.com (root@trode.redhat.com [199.183.24.80])
by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id IAA17412
for <gnome@nuclecu.unam.mx>; Mon, 26 Jan 1998 08:18:46 -0600
From: raster@redhat.com
Received: from redhat.com (raster@trode [127.0.0.1])
by trode.redhat.com (8.8.7/8.8.7) with ESMTP id JAA32753;
Mon, 26 Jan 1998 09:18:17 -0500
Message-Id: <199801261418.JAA32753@trode.redhat.com>
Date: Mon, 26 Jan 1998 09:18:13 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: Scroll bars.
To: nelson@crynwr.com
cc: gnome@nuclecu.unam.mx
In-Reply-To: <19980126141358.11542.qmail@desk.crynwr.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
On 26 Jan, Russell Nelson shouted:
-> Gregory Maxwell writes:
-> > It would be MUCH more sane to place them on the left and put the up and
-> > down (and perhaps a page up and down) button all togeather on the top or
-> > bottom..
->
-> Okay, everyone stand up and chant along with me and raster: "Themes,
-> themes, themes, themes....".
->
-> I was bitching to someone about how every X program has a different
-> graphical luser interface (GLI -- pronounced "glee", with glee). He
-> said "well, that's a good thing, because it's by no means obvious that
-> one GLI is better than another." Well, he's probably right, but
-> neither should EVERY program be different. Much better for every
-> program to access Generalized [Network] Objects (sound familiar?), and
-> let people customize ALL their programs at the same time. So if
-> someone decides that they want clustered scrollbar buttons with
-> shapes, they'll get this in the upper left-hand corner of ALL their
-> scrollable windows:
Great. Well lets talk about all of this. lets not spam gnome-list.
gnome-themes-list@gnome.org is up.. lets make good use of it. Those not
listening or mailing to it probably aren't interested in themes, so it
will reduce spam-value.
I'm excited that I could work with others here to try and acheive the
"BEST GUI FOR EVERYONE" goal.
-> +------------------------------------
-> | | |
-> | ^ | v |
-> | | |
-> |------+-----+
-> | |
-> | |
-> | |
-> | |
-> |------|
-> |WWWWWW|
-> |WWWWWW|
-> |WWWWWW|
-> |------|
-> | |
-> | |
-> | |
->
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From amundson@CompleteIS.com
Received: (qmail 21033 invoked from network); 26 Jan 1998 16:28:07 -0000
Received: from riker.completeis.com (amundson@206.144.247.10)
by mail2.redhat.com with SMTP; 26 Jan 1998 16:28:07 -0000
Received: from localhost (amundson@localhost)
by riker.CompleteIS.com (8.8.8/8.8.8) with SMTP id KAA08440;
Mon, 26 Jan 1998 10:27:57 -0600 (CST)
Date: Mon, 26 Jan 1998 10:27:56 -0600 (CST)
From: "Shawn T. Amundson" <amundson@CompleteIS.com>
X-Sender: amundson@riker
To: Gregory Maxwell <gmax@nightshade.z.ml.org>
cc: GNOME <gnome-list@gnome.org>
Subject: Re: Scroll bars.
In-Reply-To: <Pine.LNX.3.95.980126082447.9952A-100000@nightshade.z.ml.org>
Message-ID: <Pine.GSO.3.95.980126101035.6371C-100000@riker>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Scrollbars are generally on the right side so that it is easier to
line up data visually. For example, say you have something like
[label]
[label]
^
| Text
|
|
V
[Entry]
This is worse than if it where on the right where the text could
be visually lined up with the labels and entry. Lining text up
on the right side makes no sense in a majority of cases.
Also, if you put the scrollbars on the left and allow them to
automatically come up when needed, the text widget (or list
widget, etc.) would shift to the right, an extremely undesireable
action.
A general guideline in developing GUIs is that if you are going against
the grain you are most likely wrong. This is not always the case
obviously - but it is good to try and think of reasons why you should
not change standards as well.
-Shawn
On Mon, 26 Jan 1998, Gregory Maxwell wrote:
>
> Please, dont doom yet another interface with the same old stupid
> scrollbars used in almost ever GUI out there.
>
> They are inneficent and inconvient!
>
> Normally scroll bars are placed on the right side, with little up and down
> arrows on the top and bottom...
>
> This is silly.. The mouse is more often on the left (it's where the menus
> are and where text starts).. Also, going down then back up requires alot
> of mouse movement..
>
> It would be MUCH more sane to place them on the left and put the up and
> down (and perhaps a page up and down) button all togeather on the top or
> bottom..
>
> I've tried chatting with someone with KDE a long time back... But he was
> close minded.. Saying that it was too diffent from other GUIs
>
> GNOME is diffent from windows, if you are going to make something
> differnt, then do it right.. If people are goning to have to relearn
> anything then it wont be alot to ask for them to get used to the differnt
> scroll bars..
>
>
> --
> To unsubscribe: mail gnome-list-request@gnome.org with
> "unsubscribe" as the Subject.
>
--
Shawn T. Amundson Complete Internet Solutions
Senior Systems Administrator Minneapolis, Minnesota, USA
amundson@CompleteIS.com http://www.CompleteIS.com/~amundson
while (i) { last }
i, do exist.
forever;
From raster@redhat.com
Received: (qmail 18080 invoked from network); 26 Jan 1998 18:16:41 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 26 Jan 1998 18:16:41 -0000
Received: from implant.labs.redhat.com (root@implant.labs.redhat.com [207.175.45.2])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id NAA32480;
Mon, 26 Jan 1998 13:16:40 -0500
Received: from redhat.com (raster@localhost [127.0.0.1])
by implant.labs.redhat.com (8.8.7/8.8.7) with ESMTP id NAA24010;
Mon, 26 Jan 1998 13:15:48 -0500
From: raster@redhat.com
Message-Id: <199801261815.NAA24010@implant.labs.redhat.com>
Date: Mon, 26 Jan 1998 13:15:45 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: Scroll bars.
To: gnome-themes-list@gnome.org
cc: gnome-list@gnome.org
In-Reply-To: <34CCC95C.BCB71D53@rose-hulman.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
On 26 Jan, Robert J. Slover shouted:
-> Shawn T. Amundson wrote:
-> >
-> > Scrollbars are generally on the right side so that it is easier to
-> > line up data visually. For example, say you have something like
-> >
-> > [label]
-> > [label]
-> >
-> > ^
-> > | Text
-> > |
-> > |
-> > V
-> >
-> > [Entry]
-> >
-> > This is worse than if it where on the right where the text could
-> > be visually lined up with the labels and entry. Lining text up
-> > on the right side makes no sense in a majority of cases.
-> >
-> > Also, if you put the scrollbars on the left and allow them to
-> > automatically come up when needed, the text widget (or list
-> > widget, etc.) would shift to the right, an extremely undesireable
-> > action.
-> >
-> > A general guideline in developing GUIs is that if you are going against
-> > the grain you are most likely wrong. This is not always the case
-> > obviously - but it is good to try and think of reasons why you should
-> > not change standards as well.
-> >
-> > -Shawn
->
->
-> I can't agree with this. Just looking at your E-mail in netscape here,
-> the text is all crowded against the left of the page. On my nice big
-> monitor the bloody scrollbar (way over on the right) is almost out of
-> the periphary of my vision. There's an acre of empty space between the
-> ragged right side of paragraphs and my scrollbar...this makes it more
-> difficult by far to align than if my scrollbar were on the left.
->
-> Wherever I have a choice, my scrollbars are NeXT style...on the left,
-> with both up and down buttons together...and a scroll thumb that
-> corresponds in size to the percentage of the region which is visible
-> on screen. That last feature addresses your concern about magically
-> appearing scrollbars...if 100% of the region is visible the thumb
-> takes 100% of the trough. The text does not have to shift if the
-> scroll trough always exists.
->
-> I think the right hand scrollbar is just a holdover from the
-> predominant right-handedness of people...it is an almost useless
-> extension of the pick-up-and-drag metaphor. In the real world if I
-> am right handed I am likely to grab my notebook by the right side and
-> pull it across the desk towards me. This is a physical optimization
-> and doesn't need to exist in a UI.
->
-> This becomes more obvious if you use your mouse on the left. I began
-> doing this a couple of years ago at the suggestion of a russian
-> friend...it leaves my right hand free for things like cursor keys and
-> the keypad. I tend to notice the navigational overhead in having the
-> scrollbars on the right a lot more now because I now 'park' my mouse
-> at the lower left corner whereas it used to be the right. I do a
-> little less navigation to menus now though.
->
-> Also...to respond a bit to Gary Vaughan's suggestion of a 'mark' that
-> appears in the scroll trough...great idea. I've never seen that done
-> but I can immediately appreciate the uses of it. I would think the
-> GUI interaction with this might be similar to 'guides' in something
-> like PageMaker...drag a mark from a well located at one end of the
-> scrollbar and plunk it down next to the position you want to mark.
-> Grab and drag it off into the ether to clear it...simple interaction.
And this is all the more reason for themes. Let the user configure his
apps how he/she/it likes them. users can select laft/right scrollbar,
top/bottom scrollbar, arrows, no arrows, etc. etc. etc. Then there is
no argument anymore. It's a user preference. Let's not get religious
about "I like next style" or "I like win95 style" or " I like mac style"
or "I like xaw style". In the end everyone likes something different.
That, in my humble opinion, is a really good reason to discuss and get
some theme framework desgined and documented, that gives a full scope
of options for the user to modify at their leisure, and thus will allow
the programmers to start work on this, instead of waiting for some
desgin to materialize. If this isn't done now, sometime in the future
we will have springup projects like gtk-next gtk-macos gtk-E etc., with
each having different bugs, incompatabilites etc. We need to have a
framework in place that allows easy expansion and modification by users
via a gui. Whole sets of gui configs can be packaged together in themes.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From atai@ece.ucsd.edu
Received: (qmail 1167 invoked from network); 26 Jan 1998 20:16:45 -0000
Received: from mailbox2.ucsd.edu (132.239.1.54)
by mail2.redhat.com with SMTP; 26 Jan 1998 20:16:45 -0000
Received: from vision.ucsd.edu (vision.ucsd.edu [132.239.223.49])
by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id MAA03893 for
<gnome-list@gnome.org>; Mon, 26 Jan 1998 12:16:40 -0800 (PST)
Received: (from atai@localhost)
by vision.ucsd.edu (8.8.5/SOEGW-PSEUDO-4.2-SunOS-8.6.x)
id MAA23855; Mon, 26 Jan 1998 12:16:39 -0800 (PST)
for gnome-list@gnome.org
From: atai@ece.ucsd.edu (Andy Tai)
Message-Id: <199801262016.MAA23855@vision.ucsd.edu>
Subject: Re: Scroll bars.
To: gnome-list@gnome.org
Date: Mon, 26 Jan 1998 12:16:38 -0800 (PST)
In-Reply-To: <Pine.GSO.3.95.980126101035.6371C-100000@riker>
from "Shawn T. Amundson" at Jan 26, 98 10:27:56 am
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Scrollbars are generally on the right side so that it is easier to
> line up data visually. For example, say you have something like
>
> A general guideline in developing GUIs is that if you are going against
> the grain you are most likely wrong. This is not always the case
> obviously - but it is good to try and think of reasons why you should
> not change standards as well.
>
> -Shawn
>
> --
> Shawn T. Amundson Complete Internet Solutions
Yes, I totally agree with the above. One more thing is that standard
conventions have become habits of users, and thus today's definition of ease of
use includes following current conventions (what people are familiar with).
Think about a Gnome with strange layouts of scrollbars, etc. That won't
increase the acceptance of Gnome, but to work against it.
> On Mon, 26 Jan 1998, Gregory Maxwell wrote:
> >
> > Please, dont doom yet another interface with the same old stupid
> > scrollbars used in almost ever GUI out there.
That's your opinion ONLY.
--
Li-Cheng Tai (Andy Tai) e-mail: atai@ece.ucsd.edu
Free software: the software by the people, of the people and for the people,
worldwide. Develop! Share! Enhance! And enjoy!
From nelson@crynwr.com Thu May 11 23:51:22 2000
Received: (qmail 27484 invoked from network); 26 Jan 1998 20:34:01 -0000
Received: from ns.crynwr.com (192.203.178.14)
by mail2.redhat.com with SMTP; 26 Jan 1998 20:34:01 -0000
Received: (qmail 61 invoked by uid 0); 26 Jan 1998 20:34:22 -0000
Received: from desk.crynwr.com (128.153.44.67)
by ns.crynwr.com with SMTP; 26 Jan 1998 20:34:21 -0000
Received: (qmail 18245 invoked by uid 501); 26 Jan 1998 20:34:21 -0000
Date: 26 Jan 1998 20:34:21 -0000
Message-ID: <19980126203421.18244.qmail@desk.crynwr.com>
From: Russell Nelson <nelson@crynwr.com>
To: gnome-list@gnome.org
Subject: Re: Scroll bars.
In-Reply-To: <199801262016.MAA23855@vision.ucsd.edu>
References: <Pine.GSO.3.95.980126101035.6371C-100000@riker>
<199801262016.MAA23855@vision.ucsd.edu>
Andy Tai writes:
> One more thing is that standard conventions have become habits of
> users, and thus today's definition of ease of use includes
> following current conventions (what people are familiar with).
> Think about a Gnome with strange layouts of scrollbars, etc. That
> won't increase the acceptance of Gnome, but to work against it.
That's why Gnome should come with a Win95 theme, a NeXT theme, and a
Motif theme. Arguing about what is "correct" is pointless when we can
make anything be "correct".
--
-russ <nelson@crynwr.com> http://web.crynwr.com/~nelson
Crynwr Software supports freed software | PGPok | Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love,
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.
From raster@redhat.com
Received: (qmail 16446 invoked from network); 28 Jan 1998 00:42:35 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 28 Jan 1998 00:42:35 -0000
Received: from implant.labs.redhat.com (root@implant.labs.redhat.com [207.175.45.2])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id TAA27080
for <gnome-list@gnome.org>; Tue, 27 Jan 1998 19:42:35 -0500
Received: from redhat.com (raster@localhost [127.0.0.1])
by implant.labs.redhat.com (8.8.7/8.8.7) with ESMTP id TAA01790
for <gnome-list@gnome.org>; Tue, 27 Jan 1998 19:42:03 -0500
From: raster@redhat.com
Message-Id: <199801280042.TAA01790@implant.labs.redhat.com>
Date: Tue, 27 Jan 1998 19:42:00 -0500 (EST)
Reply-To: raster@redhat.com
To: gnome-list@gnome.org
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
To make the themes discussion at least constructive, I have put up a
web page detailing what at least I would call stage 1 of themes -
probably the easiest to implement, with the most effect. This is
intended to foster construcive discussion, not promote flame wars on
themes. This is a start. please take alook at:
http://www.labs.redhat.com/themes.shtml
Thankyou.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From owt1@cornell.edu
Received: (qmail 26354 invoked from network); 28 Jan 1998 21:44:02 -0000
Received: from cu-dialup-1625.cit.cornell.edu (qmailr@132.236.236.45)
by mail2.redhat.com with SMTP; 28 Jan 1998 21:44:02 -0000
Received: (qmail 8817 invoked by uid 504); 28 Jan 1998 21:46:27 -0000
To: gnome-list@gnome.org
Subject: Re: Themes [was: Unidentified subject!]
References: <199801280042.TAA01790@implant.labs.redhat.com>
From: Owen Taylor <owt1@cornell.edu>
Date: 28 Jan 1998 16:46:27 -0500
In-Reply-To: raster@redhat.com's message of Tue, 27 Jan 1998 19:42:00 -0500 (EST)
Message-ID: <lz67n4l1ak.fsf@cu-dialup-1625.cit.cornell.edu>
Lines: 55
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
raster@redhat.com writes:
> To make the themes discussion at least constructive, I have put up a
> web page detailing what at least I would call stage 1 of themes -
> probably the easiest to implement, with the most effect. This is
> intended to foster construcive discussion, not promote flame wars on
> themes. This is a start. please take alook at:
>
> http://www.labs.redhat.com/themes.shtml
(Why does Netscape insist on using a 8 point font when font
face is specified...)
- I'm curious as to how the ScaleMethod works. It seems that
in many cases you don't just want to blow up the background.
(Maybe OK for most buttons, but would be pretty awful for
a Text widget, unless the central area was just a solid color)
So, how are the edge regions handled for tiling? Is (say) the top
edge tiled horizontally?
- Is the whole pixmap (borders and all) set as the background?
This would mean putting a lot of different big pixmaps onto the
server for each different size of widget.
Also, that could have the typical background pixmap disadvantage that
if the window is resized bigger, the user will briefly see then
widgets tiled into the newly larger windows. (Because X tiles
when the background pixmap is larger than the window, for
people who aren't familiar with the effect) I suppose the
answer to that would be to set the new pixmaps _before_ resizing
the window in the size_allocate function for each widget.
- What's "Shaping Method" in the last example?
(Note that GTK just specifies the fg and background colors for
a style and constructs the shadow colors from that.)
The big question in my mind is how all of these attributes would be
specified for widgets. Note that for some widget types, several
pixmaps will have to be specified. So simply adding the attributes to
styles won't work. (unless we specify allow specifying styles for
parts of widgets.
Another question is whether alternate "standard" styles (Motif, W95,
etc.) can be specified efficiently enough with the themes mechanism
to jusitify dumping the currently non-functional style class mechanism
entirely? (Can people who want efficiency just live with the
standard GTK look?)
None of this is meant to be flammage. Just questions that came
into my mind while looking the stuff over.
Regards,
Owen
From jorgesil@microsoft.com
Received: (qmail 16852 invoked from network); 28 Jan 1998 22:06:56 -0000
Received: from mail2.microsoft.com (131.107.3.42)
by mail2.redhat.com with SMTP; 28 Jan 1998 22:06:56 -0000
Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3)
id <DZMNRK45>; Wed, 28 Jan 1998 14:06:57 -0800
Message-ID: <A1A4DA3CD56ECF11973200805F685F1680F5C9@LIS-01-MSG>
From: "Jorge Silva (Jorge Gomes da Silva)" <jorgesil@microsoft.com>
To: "'gnome-list@gnome.org'" <gnome-list@gnome.org>
Subject: RE: Themes [was: Unidentified subject!]
Date: Wed, 28 Jan 1998 13:58:14 -0800
X-Mailer: Internet Mail Service (5.5.1960.3)
Hey, let the man work. You don't like the idea but wait and see what he
comes out with. Besides you should be more constructive in your messages. I
think destroying other ppl ideas won't help a lot.
And it would be great if such talented programmers as you are could
cooperate instead of complaining about each other's ideas. Having said this
I never saw any message from Raster criticizing your work. Your "over my
dead body" sentence was very uncool.
Jorge.
> -----Original Message-----
> From: Owen Taylor [SMTP:owt1@cornell.edu]
> Sent: Wednesday, January 28, 1998 9:46 PM
> To: gnome-list@gnome.org
> Subject: Re: Themes [was: Unidentified subject!]
>
>
> raster@redhat.com writes:
>
> > To make the themes discussion at least constructive, I have put up a
> > web page detailing what at least I would call stage 1 of themes -
> > probably the easiest to implement, with the most effect. This is
> > intended to foster construcive discussion, not promote flame wars on
> > themes. This is a start. please take alook at:
> >
> > http://www.labs.redhat.com/themes.shtml
>
> (Why does Netscape insist on using a 8 point font when font
> face is specified...)
>
> - I'm curious as to how the ScaleMethod works. It seems that
> in many cases you don't just want to blow up the background.
> (Maybe OK for most buttons, but would be pretty awful for
> a Text widget, unless the central area was just a solid color)
> So, how are the edge regions handled for tiling? Is (say) the top
> edge tiled horizontally?
>
> - Is the whole pixmap (borders and all) set as the background?
> This would mean putting a lot of different big pixmaps onto the
> server for each different size of widget.
>
> Also, that could have the typical background pixmap disadvantage that
> if the window is resized bigger, the user will briefly see then
> widgets tiled into the newly larger windows. (Because X tiles
> when the background pixmap is larger than the window, for
> people who aren't familiar with the effect) I suppose the
> answer to that would be to set the new pixmaps _before_ resizing
> the window in the size_allocate function for each widget.
>
> - What's "Shaping Method" in the last example?
>
> (Note that GTK just specifies the fg and background colors for
> a style and constructs the shadow colors from that.)
>
> The big question in my mind is how all of these attributes would be
> specified for widgets. Note that for some widget types, several
> pixmaps will have to be specified. So simply adding the attributes to
> styles won't work. (unless we specify allow specifying styles for
> parts of widgets.
>
> Another question is whether alternate "standard" styles (Motif, W95,
> etc.) can be specified efficiently enough with the themes mechanism
> to jusitify dumping the currently non-functional style class mechanism
> entirely? (Can people who want efficiency just live with the
> standard GTK look?)
>
> None of this is meant to be flammage. Just questions that came
> into my mind while looking the stuff over.
>
> Regards,
> Owen
>
>
> --
> To unsubscribe: mail gnome-list-request@gnome.org with
> "unsubscribe" as the Subject.
From otaylor@cu-dialup-1625.cit.cornell.edu
Received: (qmail 5301 invoked from network); 28 Jan 1998 22:47:27 -0000
Received: from cu-dialup-1625.cit.cornell.edu (qmailr@132.236.236.45)
by mail2.redhat.com with SMTP; 28 Jan 1998 22:47:27 -0000
Received: (qmail 9227 invoked from smtpd); 28 Jan 1998 22:49:50 -0000
Received: from localhost (HELO cu-dialup-1625.cit.cornell.edu) (otaylor@127.0.0.1)
by localhost with SMTP; 28 Jan 1998 22:49:50 -0000
From: Owen Taylor <owt1@cornell.edu>
To: "Jorge Silva \(Jorge Gomes da Silva\)" <jorgesil@microsoft.com>
cc: "'gnome-list@gnome.org'" <gnome-list@gnome.org>
Subject: Re: Themes [was: Unidentified subject!]
In-reply-to: Your message of "Wed, 28 Jan 1998 13:58:14 PST."
<A1A4DA3CD56ECF11973200805F685F1680F5C9@LIS-01-MSG>
Date: Wed, 28 Jan 1998 17:49:48 -0500
Sender: otaylor@cu-dialup-1625.cit.cornell.edu
[ Since it wasn't private, I feel I should respond publically ]
"Jorge Silva \(Jorge Gomes da Silva\)" <jorgesil@microsoft.com> writes:
> Hey, let the man work. You don't like the idea but wait and see what he
> comes out with. Besides you should be more constructive in your messages. I
> think destroying other ppl ideas won't help a lot.
Read my message again. What there wasn't constructive? What there
wasn't polite? I think you'll find that my message even pretty much
implies that I think themes are a reasonable thing to add to GTK.
(I never was one of the people flaming themes in general...)
If Raster didn't want any comments he presumably would not have
asked for them. (And just to emphasize a point, there is no
"war" going on between us. Since that one somewhat acrimonious
discussion, I think we have managed to keep things on a quite
friendly level.)
> And it would be great if such talented programmers as you are could
> cooperate instead of complaining about each other's ideas. Having said this
> I never saw any message from Raster criticizing your work.
We could all work in closets and come out with our individual versions
of GTK. I don't think that would be helpful. If some parts of my work
needs improvement, I hope Raster (and everybody else) will tell me
about it. There are limits to how much time I want to spend on email -
so I may respond mostly to things I disagree with, rather than to
things I do agree with, but my intent is never to "cut down" anybody's
work.
> Your "over my dead body" sentence was very uncool.
If you look when I actually said the above quote, I think you'll find
that you are taking it quite out of context.
Regards,
Owen
From raster@redhat.com
Received: (qmail 14510 invoked from network); 29 Jan 1998 21:10:53 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 29 Jan 1998 21:10:53 -0000
Received: from implant.labs.redhat.com (root@implant.labs.redhat.com [207.175.45.2])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id QAA14230;
Thu, 29 Jan 1998 16:10:52 -0500
Received: from redhat.com (raster@localhost [127.0.0.1])
by implant.labs.redhat.com (8.8.7/8.8.7) with ESMTP id QAA06331;
Thu, 29 Jan 1998 16:10:19 -0500
From: raster@redhat.com
Message-Id: <199801292110.QAA06331@implant.labs.redhat.com>
Date: Thu, 29 Jan 1998 16:10:16 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: Themes [was: Unidentified subject!]
To: owt1@cornell.edu
cc: gnome-list@gnome.org
In-Reply-To: <lz67n4l1ak.fsf@cu-dialup-1625.cit.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
On 28 Jan, Owen Taylor shouted:
->
-> raster@redhat.com writes:
->
-> > To make the themes discussion at least constructive, I have put up a
-> > web page detailing what at least I would call stage 1 of themes -
-> > probably the easiest to implement, with the most effect. This is
-> > intended to foster construcive discussion, not promote flame wars on
-> > themes. This is a start. please take alook at:
-> >
-> > http://www.labs.redhat.com/themes.shtml
->
-> (Why does Netscape insist on using a 8 point font when font
-> face is specified...)
->
-> - I'm curious as to how the ScaleMethod works. It seems that
-> in many cases you don't just want to blow up the background.
-> (Maybe OK for most buttons, but would be pretty awful for
-> a Text widget, unless the central area was just a solid color)
-> So, how are the edge regions handled for tiling? Is (say) the top
-> edge tiled horizontally?
ScaleMethod - in at least the plan there merely determines the size of
the pixmap - that is just set to the background and tiled.. if the size
is the same as the widget - the tiling is not apparent.
Is what you're getting at when you have a large expanse.. you might
wish to use a pixmap to deinfe the borders (for lets say soft slightly
rounded borders) but keep the center single-coloured or tiled? I see
your point being - you'd have a pixmap the size of the whole text area
just to decorate it - the middle parts being mainly one color. What you
want is to split the pixmap into separate parts.. right? corners,
edges, middle and define different properties for them?
This would solve that problem - but it would be rather more compilcated
to write the code... Is this what your point was?
-> - Is the whole pixmap (borders and all) set as the background?
-> This would mean putting a lot of different big pixmaps onto the
-> server for each different size of widget.
Yes. borders are part of the pixmap - but you can just tile one for
"patterns" but to get a unique effect you would need to do this. Imlib
handles naieve code and shares pixmap id's for the smae sized pixmap
scaled from the same original image data.
Can you think of a way arpund this but still allow the same effect?
-> Also, that could have the typical background pixmap disadvantage that
-> if the window is resized bigger, the user will briefly see then
-> widgets tiled into the newly larger windows. (Because X tiles
-> when the background pixmap is larger than the window, for
-> people who aren't familiar with the effect) I suppose the
-> answer to that would be to set the new pixmaps _before_ resizing
-> the window in the size_allocate function for each widget.
But currently you see a brief blanking of areas - which is a similar
effect. I perosnally see that as a moot point. - and yes.. my code
normally does:
scale_image();
free_previous_pixmap();
setbg_pixmap();
resize();
clear_window();
-> - What's "Shaping Method" in the last example?
It's just on or off - if on it can optionally specify a color to be
transparent if the image format doesn't have it. In the last example
its OFF.
-> (Note that GTK just specifies the fg and background colors for
-> a style and constructs the shadow colors from that.)
True.. but the data structs contain gc's for them all. i was being a
little more explicit for themes.
-> The big question in my mind is how all of these attributes would be
-> specified for widgets. Note that for some widget types, several
-> pixmaps will have to be specified. So simply adding the attributes to
-> styles won't work. (unless we specify allow specifying styles for
-> parts of widgets.
Hmm yes. I realise (for example - scrollbar - scollbar pixmap, arrow
pixmaps (2), trought pixmaps - then differnt styles per state). I am
"ignoring" that for now and just concentrating on the button - and take
the same principals and expand them to to other widgets.
-> Another question is whether alternate "standard" styles (Motif, W95,
-> etc.) can be specified efficiently enough with the themes mechanism
-> to jusitify dumping the currently non-functional style class mechanism
-> entirely? (Can people who want efficiency just live with the
-> standard GTK look?)
No - because those themes are meostly replacements of the bevel drawing
code (mostly) They can be specified, but will require pixmaps under the
aobe scheme - I suppose there should be another attribute defining how
to draw a bevel. I have never thought of this before myself, so input
would be nice. I generalised on the pixmap being able to describe any
bevel - maybe at the expense of memory. If we can have a bevel
defintion that can define the current bevel style and include others -
even beyond just motif/win95/next bevels - but a bit further, then this
would be great - and most probably the only glaring hole I can see.
-> None of this is meant to be flammage. Just questions that came
-> into my mind while looking the stuff over.
->
-> Regards,
-> Owen
->
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From owt1@cornell.edu
Received: (qmail 18222 invoked from network); 30 Jan 1998 01:47:16 -0000
Received: from cu-dialup-1224.cit.cornell.edu (qmailr@132.236.155.198)
by mail2.redhat.com with SMTP; 30 Jan 1998 01:47:16 -0000
Received: (qmail 20712 invoked by uid 504); 30 Jan 1998 01:49:39 -0000
To: gnome-list@gnome.org
Subject: Re: Themes [was: Unidentified subject!]
References: <199801292110.QAA06331@implant.labs.redhat.com>
From: Owen Taylor <owt1@cornell.edu>
Date: 29 Jan 1998 20:49:39 -0500
In-Reply-To: raster@redhat.com's message of Thu, 29 Jan 1998 16:10:16 -0500 (EST)
Message-ID: <lz4t2m7mto.fsf@cu-dialup-1224.cit.cornell.edu>
Lines: 136
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
raster@redhat.com writes:
> On 28 Jan, Owen Taylor shouted:
> -> =
> -> - I'm curious as to how the ScaleMethod works. It seems that
> -> in many cases you don't just want to blow up the background.
> -> (Maybe OK for most buttons, but would be pretty awful for
> -> a Text widget, unless the central area was just a solid color) =
> -> So, how are the edge regions handled for tiling? Is (say) the top=
> -> edge tiled horizontally?
> =
> ScaleMethod - in at least the plan there merely determines the size of
> the pixmap - that is just set to the background and tiled.. if the size=
> is the same as the widget - the tiling is not apparent.
> =
> Is what you're getting at when you have a large expanse.. you might
> wish to use a pixmap to deinfe the borders (for lets say soft slightly
> rounded borders) but keep the center single-coloured or tiled? I see
> your point being - you'd have a pixmap the size of the whole text area
> just to decorate it - the middle parts being mainly one color. What you=
> want is to split the pixmap into separate parts.. right? corners,
> edges, middle and define different properties for them?
> =
> This would solve that problem - but it would be rather more compilcated=
> to write the code... Is this what your point was?
Yes, that was my point. For big expanses with borders, even if
you leave aside questions of storing the background pixmaps, if =
you want a tiled background for the center portion, then scaling
will probably give suboptimal results.
=46rom the purely visual point of view, you could use the division
of the pixmap into regions you proposed, but simply tile everything
but the corners when they need to be expanded. (There is a question
of fitting the parts together - possibly a combination of scaling
within a small range and integer tiling would be needed)
I can see three basic ways to implement this
- Draw the whole thing onto one pixmap, and use it as a background
for the window. A bit wasteful in server memory (since many
portions are just tiled) and in speed (since the client has
to do the tiling itself) but good appearance.
- Divide the window into nine subwindows, and set up a separate
background on each. Subwindows may be cheap but 9x ?
- Set the middle portion as the window background. Then draw
in the borders with XCopyArea. Least overhead in server
memory, but could mean a lot of calls to draw the border.
(This could be alleviated by forming long thin pre-tiled sections
of the edge pixmaps, so that you would only need 8 calls
to do the border - less than if you were drawing with bezels)
This would require the most restructuring of GTK code (but
still not that much). =
> -> - Is the whole pixmap (borders and all) set as the background?
> -> This would mean putting a lot of different big pixmaps onto the
> -> server for each different size of widget. =
> =
> Yes. borders are part of the pixmap - but you can just tile one for
> "patterns" but to get a unique effect you would need to do this. Imlib
> handles naieve code and shares pixmap id's for the smae sized pixmap
> scaled from the same original image data.
Sharing pixmaps helps if you have lots of identically sized buttons
(gnomine?) I don't think this happens too much in general GTK
code though.
=
> Can you think of a way arpund this but still allow the same effect?
See above. Though none are completely satisfactory.
[ ... ]
> -> The big question in my mind is how all of these attributes would be=
> -> specified for widgets. Note that for some widget types, several
> -> pixmaps will have to be specified. So simply adding the attributes =
to
> -> styles won't work. (unless we specify allow specifying styles for =
> -> parts of widgets.
> =
> Hmm yes. I realise (for example - scrollbar - scollbar pixmap, arrow
> pixmaps (2), trought pixmaps - then differnt styles per state). I am
> "ignoring" that for now and just concentrating on the button - and take=
> the same principals and expand them to to other widgets.
Its possible that decent results can be obtained by just setting
up themes for the easy widgets, and using a consitent bezel color/lightin=
g
style for the rest. But I think the question of how to specify
more is worth actively considering. (So we don't have to break
everybodies themes when the rest is added).
> -> Another question is whether alternate "standard" styles (Motif, W95=
,
> -> etc.) can be specified efficiently enough with the themes mechanism=
> -> to jusitify dumping the currently non-functional style class mechan=
ism
> -> entirely? (Can people who want efficiency just live with the =
> -> standard GTK look?)
> =
> No - because those themes are meostly replacements of the bevel drawing=
> code (mostly) They can be specified, but will require pixmaps under the=
> aobe scheme - I suppose there should be another attribute defining how
> to draw a bevel. I have never thought of this before myself, so input
> would be nice. I generalised on the pixmap being able to describe any
> bevel - maybe at the expense of memory. If we can have a bevel
> defintion that can define the current bevel style and include others -
> even beyond just motif/win95/next bevels - but a bit further, then this=
> would be great - and most probably the only glaring hole I can see.
The original GTK code assumes that seperate bezel-drawing routines
will be written and linked in for each style. Which isn't too
conducive to post-hoc user modification.
Using pixmaps to do the borders in one of the modes outlined above
is probably the most general method. (Although it cannot be adopted
arbitrary shaded polygons as in gtk_draw_polygon). Another possibility
is to specify a sequence of intensity levels for the edges and
draw the bevels as lines using appropriate colors. My visual
memory for Win96 and Next looks isn't good enough to say if this
is sufficient.
(If the description isn't clear, I mean that GTK's current style
woudl be specified as something like:
OUT: topleft=3D[white light] bottomright=3D[dark black]
IN: topleft=3D[dark black] bottomright=3D[white light]
Very roughly... For Motif's 1-pixel style there would only be
one color specified for each edge)
(One tricky thing to think about is the "knob" in the center
of the Next scrollbars ... can that be handled without adding
a special "knob subwindow" onto every GTK scrollbar?)
Owen