[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GUI design mix
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] GUI design mix |
Date: |
Fri, 16 Jul 2004 14:25:34 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> I can only speak for myself but the current mix of GUI designs came about
> because it was much easier for me to simply hack notebookplugins. All one has
> to do do is add a few lines to a plugin and voila it shows up as a notebook
> tab.
That pretty much sums it up. We had functional needs and
solved them. Easiest - and one of the acceptable ways to go
about it - was the notebook plugin. So we did it. Period.
> in the first place. I like the Richard space design very much and always
> planned on converting my plugins to it but that never reached priority high
It seems people STILL don't get it. The functional part of
a GUI widget doesn't care in the least where you put it. It
has no preference of notebook plugin over Richard space
plugin. It just wants a parent pointer to display it's, say,
wxPanel in. To allow for that wrapers have to be written for
the various plugin manager - a) Horst space notebook, b)
Richard space left-hand pane. The Horst space wrappers live in
wxpython/gui/. Now, those aren't factored out appropriately,
but we have done some work on that. Look at EMR text dump, lab
journal, show lab, vaccinations.
The big mess was that the plugin wrapper code was intertwined
between Horst space and Richard space. I have forcefully
separated them a few weeks ago which made the Horst space
plugins enjoyably simpler than before. I haven't scrapped any
of Richard space but they are in limbo.
> I don't know if we have reached a consensus on that but I would prefer either
> notebook tab design or integrated Richard design.
You can have that with a configuration setting. Either or. Ian
convinced me that that was possible. However, the first
implementation erred on the part of, again, creating
super-plugins by reusing the *notebook plugin* code in
Richard space.
> The way I see it we need to get this separation done.
It is being worked on at the moment.
> Once this has been done
> I would welcome if anyone who knows Richardspace enough could convert let's
> say the labdata plugin and integrate it into Richard space. I would be more
> than happy to learn from that and make my other plugins (LabJournal,
> gmSacanMedDocs, gmIndexMedDocs, gmShowMedDocs ) fit for Richard space.
Friggin' no !! Write wrappers which ALSO LOAD them in
Richard space - if that makes sense at all - they don't really
fit in with the edit area paradigm. Along the way some
separation into plugin wrapper and functionality code may be
needed. But that's needed anyways.
I am trying to make sure we don't get this wrong.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] Ok - I'm up and running - project needed., Jim Busser, 2004/07/16
Re: [Gnumed-devel] Ok - I'm up and running - project needed., Karsten Hilbert, 2004/07/16
Re: [Gnumed-devel] Ok - I'm up and running - project needed., Karsten Hilbert, 2004/07/16
Re: [Gnumed-devel] Ok - I'm up and running - project needed., Karsten Hilbert, 2004/07/16