[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] artwork handling
From: |
Richard Terry |
Subject: |
Re: [Gnumed-devel] artwork handling |
Date: |
Mon, 21 Mar 2005 08:55:22 +1100 |
User-agent: |
KMail/1.5.4 |
Having used iimg2py extensively and embedding icons over the last 2 years, I
think is is a MAJOR PAIN, though theoretically a better solution in the final
stages of development.
There is much much more flexibility in using a bitmaps subdirectory. The
problem with putting all the images in a file is just what has been
previously alluded to - you can't find one if you want to, if you want to
change an icon size, colour etc, you have to re-compile the whole file.
The advantages are you don't lose, overwrite icons.
I think that until a final release, images should be in a subdirectory, and
later during a final release, should probably be embedded in the actual file
using them, as we have done in the past.
Richard
On Sun, 20 Mar 2005 06:28 pm, Sebastian Hilbert wrote:
> > Sebastian Hilbert wrote:
> > > GNUmed uses icons. These icons can either be *.png images (any directly
> > > supported by wxwidgets directly) or a *.png image converted to a *.py
> >
> > file
> >
> > > by img2py.
> >
> > Personally I loathe this practice and would much prefer all client icons
> > under
> > client/bitmaps as separate files.
>
> Right now it is pretty much up to the people on this list. Actually I don't
> expect much input.
>
> You stated what you prefer
> I will go with one of them, no matter which one. I tend to like originals
> better.
>
> > I don't know of any advantages of embedding files in python code,
> > the disadvantages you discuss. (namely, can't be edited)
>
> img2py must have been written for a reason. I would like to see an editor
> like that. I think I said that before but this would be beneficial to
> everyone in the python community.
>
> > But, like so many things, having to support both is far worse than either
> > alone,
>
> Absolutely
>
> > so we should junk client/bitmpas if the majority want img2py.
>
> Right now the majority is you and me :-).
>
> > Wait, there *is* an advantage: if we stop scanning client/wxpython/gui
> > for modules too,
> > the client now has no need to hunt on the local filesystem for its own
> > directory
> > once PYTHONPATH is set up, this makes the packager's job slightly easier.
>
> This sounds reasonable to me. I don't know if there is any speed penalty
> with using py files. Maybe there even is an advantage because icons might
> be stored in memory and reused.
>
> > > I think not. I would store patient images in its original file format
> > > in
> >
> > the
> >
> > > database. Much like we do it with archive content right now.
> > > This preserves exif information (date, rotation, shutter speed) from
> >
> > digital
> >
> > > cameras I hope.
> >
> > Correct. Patient images are a totally seperate issue.
>
> That is what I thought.
>
> > wxWindows is responsible for displaying them: again we as gnumed coders
> > don't care what format they are in.
> > wxWindows supports all the common formats.
>
> Ah, good to know.
>
>
> For the record. The minute I see a tool for handling images embedded in
> python file I am for it. If not I would go for using originals.
>
> Awaiting more input. I will make a decision in a week or so. Maybe earlier.
>
> The decision making for GNUmed is still on. Right now it looks like I will
> change all occurences I can find. Or is anybody else willing to do this?
>
> Maybe someone with scripting skills ?
>
> Sebastian
Re: [Gnumed-devel] artwork handling, Karsten Hilbert, 2005/03/20