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

List:       kde-look
Subject:    Re: Color palettes services...
From:       Dave Leigh <dave.leigh () cratchit ! org>
Date:       2002-07-15 2:09:51
[Download RAW message or body]

On Sunday 14 July 2002 15:28, Friedrich W. H. Kossebau wrote:
> Dave Leigh schrieb:
> > I may have misunderstood your intention, but if so, my reply should make
> > it clear how I've misunderstood you, and you can correct me.
>
> Well, blaim it on my problems to use the english language correctly,
> missing the right terms :(

No problem. English is terribly imprecise. Lewis Carroll wrote, "When I use a 
word it means precisely what I intend it to mean, neither more nor less." I 
express the same thought by saying, "English is the XML of linquistics: every 
conversation should be accompanied by a schema." Native speakers (me 
included) often have as much trouble as you.

> I was thinking of this:
>
> CASE A: You select color "company's red" of the palette "corporate
> colors" to be the color of the background of a company's flyer. In the
> meantime your company's stylist has to make sense to him being enganged
> and presents a slightly modified corporate identity, making the
> company's red a little more red.

Thanks for the Use Case. I agree with the UML approach to software design; 
it's always easier to understand the proposer's intent when he provides Use 
Cases.

I might understand what you suggest. I'm not sure that I agree with it. It 
will take a little talking through it before I'm convinced it's a good idea. 
I'm going to try shooting holes in it and you see if I can plug them. You can 
try to plug any holes I leave (or tell me why it's bulletproof). BTW, I might 
contradict myself as I go along. If so, the last thing I type is my 
conclusion. In other words, I'm thinking as I type, so you can see my thought 
process:

First, some observations:

1. In your Use Cases you've got some colors that come from the default 
palette and some that come from a shared user-defined palette. I presume that 
in addition to the shared palette you might also have private palettes.

2. Based on your Use Cases, the palette approach requires you to put color 
references inside the documents instead of colors.  Not only do you need to 
put the color_id, but you have to define exactly WHICH PALETTE each color 
came from. 

3. We don't need to be concerned about CASE B, since you don't typically 
share desktop widgets outside of your local network. Our primary concern 
should be documents.

4. Palettes MUST be included in the documents, or my earlier complaints 
concerning portability are still valid. Without a palette stored in every 
file, then even though the file format is XML, the file is only useful if the 
palette service is active. This would be contrary to the intent of XML, which 
is portability. Even another Unix system couldn't use the file unless it 
provided an equivalent of the palette service or the document contains the 
palette. I love KDE, but I have no desire to see KDE documents locked into 
KDE applications. A Windows programmer should be write an editor that is able 
to read and manipulate a KWord file as easily as it's done in KDE itself. 
That's what open file formats are all about.

5. If you send a file to someone outside your company (to a customer, for 
example) then you've still got a potential portability problem, even if he's 
got KDE and even if he's got a palette service running! His palettes are 
still not necessarily the same as yours. Again, you've got to include the 
palette or send it separately. You said, "Then the app has to stick with the 
stored values of last update," but what exactly does that MEAN? Can there be 
a stored value anywhere except inside the document? I don't think so. And If 
you did send it separately, it would seem to me that this approach prefers 
the service's palette instead of the most recent palette. The customer might 
not have your recent changes.

6. The concept of storing the colors locally but preferring the global values 
is contrary to standard practice. Normally local values override global 
values.

7. Once you start including the palette in the document, there might not 
really *much* benefit over putting the colors there in the first place (as I 
mentioned in my previous post). But there might be *some* additional value to 
your approach, so I'll try to describe an implementation below.

8. Existing document formats don't use palettes. HTML doesn't, for example. 
And the Use Case you provide is most useful in the case of an HTML document. 
And it takes an international committee to make changes to the format. On the 
other hand, you could serve up the web page using any scripting language, and 
any of them could provide exactly what you propose with nothing more than a 
text file or a hash table. Therefore, what we're talking about includes 
changing the file format of all KDE-generated documents.


"Thought Implementation": 

I'd be interested to see a reference implementation, even if it's not real. 
Your example uses each color for a particular purpose. For this sort of 
thing, I'd suggest you're best off with a simple table or XML file where you 
reference colors by name. Maybe like this pseudo-example:

  <palette name="mypalette">
    <palettecolor name="company_document_background" value="#FFFFFF" />
    <palettecolor name="company_document_text" value="#FF0000" />
  </palette>

Then in your document you might have something like:

...text text text text <font palette="mypalette" 
palettecolor="company_document_text">redtext</font> text text text...

This pseudo-example is an attempt to work it into an XML format based on HTML 
that's still readable by a standard browser (even if the colors are ignored 
(because undefined tags are ignored in HTML)). Absolute colors could still be 
included by using standard HTML syntax. With this approach you could include 
the palette in the document and it would still be readable. You can store 
multiple palettes in a single doc if necessary.

If the service or the palette is unavailable, then the palette stored in the 
doc is what's used. Of course, any KDE app designed to read this file would 
ignore the stored palette and get the colors from the color service if the 
service has a palette named "mypalette" accessible to it. When the file is 
saved again, the entire palette is copied from the service and included in 
the doc. A Windows programmer wanting to write an editor for this filetype 
doesn't need to depend on a service.

This approach doesn't REALLY update the colors in every document as you 
suggested in your first post, but it APPEARS to, since your application 
simply ignores the values stored in the file, and uses the service's palette 
instead.

Is this what you meant?

-- 
Dave Leigh, Consulting Systems Analyst
Cratchit.org
  http://www.cratchit.org
  864-427-7008 (direct)
  AIM or Yahoo!: leighdf
  MSN: leighdf29379@hotmail.com
  ICQ: 37839381

How kind of you to be willing to live someone's life for them.

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