 | | | | | |
In lugnet.cad.dev, Kyle McDonald wrote:
> How about a ldcfgblk.ldr? For those of us who prefer to edit on a
> black background instead of a paper white one?
>
> I suppose the software could just swap edge=0 for edge=8 and vice
> versa, but what about the non-black and white edges?
I'd say we're getting to the point where -- if there are going to be more than a
handful of color configurations -- we'd want to think about some alternate
distribution/management methods for 'color configurations'. Similar to what
other softwares do with downloading 'skins'.
Steve
| | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote:
> In lugnet.cad.dev, Kyle McDonald wrote:
>
> > How about a ldcfgblk.ldr? For those of us who prefer to edit on a
> > black background instead of a paper white one?
> >
> > I suppose the software could just swap edge=0 for edge=8 and vice
> > versa, but what about the non-black and white edges?
>
>
> I'd say we're getting to the point where -- if there are going to be more than a
> handful of color configurations -- we'd want to think about some alternate
> distribution/management methods for 'color configurations'. Similar to what
> other softwares do with downloading 'skins'.
That sounds sensible.
Also it's occurred to me since my last post on the
internationization topic, that the Color names, and color
definitions might be better off split up.
1. If the skins or theme's catch on, there's no sense having a
'localized' version of every theme.
2. When a new color is added or an old one updated, who wants to
have to go and edit every copy with the same data.
Seems easier to have the numeric vales in one file and the names
in multiple other files. Maybe the default (or 'C' Locale ;) )
names are in with the numeric definitons, and you only need an
colornames file if you want different names?
-Kyle
--
_
-------------------------ooO( )Ooo--------------------------------
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. ||||| Kyle.McDonald@Sun.COM
1 Network Drive \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o) fax: (781) 442-1542
--------------------------------ooO(_)Ooo-------------------------
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Kyle McDonald wrote:
> Also it's occurred to me since my last post on the
> internationization topic, that the Color names, and color
> definitions might be better off split up.
Yes ... and no.
If we did produce a fully internationalized, multi-namable color definition set,
we'd almost certainly include a 'default name' property for the colors.
So think of the data in ldconfig.ldr as the color definitions + the default
names.
If anyone wants to work on a definition of a language file, with info like...
ldlang-en.ldr:
0 COLOURNAME 0 Black
(I'm mono-lingual, so this is as far as the example is going to go)
... that would be cool.
But I feel fairly strongly that international color-name-lists really belong in
the upcoming color database, not in the LDraw distribution.
Steve
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Kyle McDonald wrote:
> > How about a ldcfgblk.ldr? For those of us who prefer to edit on a
> > black background instead of a paper white one?
> >
> > I suppose the software could just swap edge=0 for edge=8 and vice
> > versa, but what about the non-black and white edges?
>
> I'd say we're getting to the point where -- if there are going to be more than a
> handful of color configurations -- we'd want to think about some alternate
> distribution/management methods for 'color configurations'. Similar to what
> other softwares do with downloading 'skins'.
>
> Steve
The more I think about it, the more I lean towards ldconfig.ldr should stick to
handle just 'color definitions' and just default border colors, rather than
'color configurations'. Where 'default' is the traditional "anti-color" that
optionally can be overruled by user's preferences. Isn't it better if 'color
configurations' were kept in ldraw.ini, alternatively in the different programs'
ini files respectively?
While brainstorming, I really would like to see the option "No line type 2 or
5", too. This is the option I personally use much, much more often than "Show
color 24 as black".
/Tore
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Tore Eriksson wrote:
> While brainstorming, I really would like to see the option "No line type 2 or
> 5", too. This is the option I personally use much, much more often than "Show
> color 24 as black".
<SHAMELESS_PLUG>
That's easy, just use LDView ;-).
</SHAMELESS_PLUG>
It won't let you turn off all type 2 lines, but it will let you turn off all
"edge lines", which are all type 5 lines, and all type 2 lines that are color
24. To be honest, I don't think turning off all type 2 lines would be useful.
However, if you have a legitimate use for this, let me know; it would be easy
enough to add to LDView.
Of course, L3Lab supports turning on and off each individual line type
separately, so I'm not sure where you want to see the option "No line type 2 or
5".
--Travis
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Tore Eriksson wrote:
> > While brainstorming, I really would like to see the option "No line type 2 or
> > 5", too. This is the option I personally use much, much more often than "Show
> > color 24 as black".
>
> <SHAMELESS_PLUG>
> That's easy, just use LDView ;-).
> </SHAMELESS_PLUG>
>
> It won't let you turn off all type 2 lines, but it will let you turn off all
> "edge lines", which are all type 5 lines, and all type 2 lines that are color
> 24. To be honest, I don't think turning off all type 2 lines would be useful.
> However, if you have a legitimate use for this, let me know; it would be easy
> enough to add to LDView.
>
> Of course, L3Lab supports turning on and off each individual line type
> separately, so I'm not sure where you want to see the option "No line type 2 or
> 5".
The very big problem with all the nice options in L3Lab is that they aren't
saved anywhere. One place to put all those options stored would be the
ldconfig.ldr file, but I think it would be more natural to put it in ldraw.ini
or a program-specific ini file.
Legitimate or not, I use a handful of personal custom settings when viewing
large portions of Datsville. First of all, turning off all edge lines saves a
lot of rendering time. When scaled down to, say 8%, those lines are so dense
that they more or less destroy the picture. If I don't remember wrong, the whole
Datsville takes 45 seconds in L3Lab after I double-clicked on town.ldr. With all
my favourite options, the same model takes maybe 6 seconds or less. It is very
annoying to have to go through all these options each time I accidently happened
to close the viewer.
I don't remember the reason I've picked L3Lab instead of LDView. But it must
have been eather stability issues or rendering speed. Sorry for that. :)
/Tore
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Tore Eriksson wrote:
> Legitimate or not, I use a handful of personal custom settings when viewing
> large portions of Datsville. First of all, turning off all edge lines saves a
> lot of rendering time. When scaled down to, say 8%, those lines are so dense
> that they more or less destroy the picture. If I don't remember wrong, the whole
> Datsville takes 45 seconds in L3Lab after I double-clicked on town.ldr. With all
> my favourite options, the same model takes maybe 6 seconds or less. It is very
> annoying to have to go through all these options each time I accidently happened
> to close the viewer.
>
> I don't remember the reason I've picked L3Lab instead of LDView. But it must
> have been eather stability issues or rendering speed. Sorry for that. :)
Well, if you look at Datsville a lot, that would probably be the reason. It
won't open in any version of LDView released to date. The next major LDView
release (3.0) will open it. I just opened town.dat, and while it took 25
seconds to load the file, it displayed it (and updated the display) in about a
second. That's just fast enough to interact without being too annoyed. Of
course, that's with an ATI 9700 Pro video card, which is fairly fast for
geometry.
--Travis
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Tore Eriksson wrote:
> The more I think about it, the more I lean towards ldconfig.ldr should
> stick to handle just 'color definitions' and just default border colors,
> rather than 'color configurations'. Where 'default' is the traditional
> "anti-color" that optionally can be overruled by user's preferences. Isn't
> it better if 'color configurations' were kept in ldraw.ini, alternatively
> in the different programs' ini files respectively?
I agree that ldconfig.ldr should stay simple.
But it should be possible for people to create and use alternate configuration
files, including (but not limited to) alternate color definitions.
Let's see, that's 4, or maybe 5, votes for 'traditional' edge colors.
Steve
| | | | | | |
