Re: [Gnumed-devel] GUI design mix

[Richard Terry]

Karsten, it must be pretty early on your side of the world ? around 9am!

Shame on you (but of course I understand!)  for not reading the design 
documents. You should at least read www.gnumed.net/rterry/Index.htm because 
you would immediately see the validity of the concept.

I will happily make it a co-project to convert your lab-data stuff, or the 
scandoc stuff - in fact - can you view scan doc's, I'd assume so, if so that 
would be by far the easiest one to convert to the screen concept.

Now that I'm grudgingly back in debian until someone fixes egenix for ARCH - 
(there's a guy from switzerland on the arch list studying molecular biology 
who is responsible for the egenix maintenance for arch who seems to know what 
the problem is and says he will fix it after his exams coming up soon),g I'll 
stay here for a while and do some gnuMed work.

Regards

richard


On Fri, 16 Jul 2004 04:28 pm, Sebastian Hilbert wrote:
> From my perspective this is not an issue of what is conceptually superior.
> It is and most likely always will be an issue of simply *doing* things.
>
> 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.
>
> This is simply the result of me not having enough time to do it
> right/better 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 enough to actually get *done*. Does that make things clear ?
>
> I shamefully admit never to have read the design documents in the wiki. I
> know they are there. I point other people to it. But I never made use of
> them.
>
> Is there a description somwhere of what one needs to do to convert a plugin
> from notebook style to Richard style. I have a strange feeling I don't even
> know what that means.
>
> I don't know if we have reached a consensus on that but I would prefer
> either notebook tab design or integrated Richard design.
>
> The way I see it we need to get this separation done. 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.
>
> So if that gets done within the next five weaks (earliest :-) ) I could
> start hacking again right after my exams.
>
> > snip >
> >
> > >I and others would think
> > > we should still post any worries or concerns, trusting Richard will at
> > > least note them, and give them due consideration before disregarding,
> > > if that is his decision. Richard would need to advise whether "blindly"
> > > means no questions, or whether alternative views are welcome along the
> > > way, maybe sent to him and Ian privately, but without them having to
> > > feel the need to explain or defend everything along the way.
> >
> > Obviously everyone should still comment/postconcerns/raise
> > objections/point out other possibilities.
> >
> > My interest in this is not to just push my paradigm, but to ensure gnuMed
> > gets running with the best possible functionality - and I don't presume
> > to beleive that I alone can do that. In fact the current mixture contains
> > elements from many different inputs, and quite rightly so.
> >
> >  Where I think I have the skill is to integrate much of this both
> > visually and functionally.
> >
> > The current SOAPtext control is a good example. The edit area's I
> > designed in VB work brilliantly, in part because vb is visually and
> > programmatically easier than wxPython, but there are inherent design
> > problems in wxPython. However, having put out my functionality wish-list
> > to the list, Ian was able to do the coding to modify the programming
> > editor as I suggested to form the basis for an improved version of the
> > editing area concept. Karsten originally took my popup word suggestion
> > lists as used in VB and implemented it in wxPython, python etc.
> >
> > >if I can reference the John Belushi
> > > film "Animal House", to NOT listen to the devil on the left shoulder
> > > saying "where does Richard get off, thinking he is the master and we
> > > are the slave" and instead think "let's cut him however much slack I/we
> > > can". Any pessimists can even reserve the right to expect to be able to
> > > say (silently I hope) "I told you so", but hopefully with a *sliver* of
> > > willingness to be proven wrong.
> >
> > I would hope people are not so thin skinned as to say "where does richard
> > get off thinking he is master......", that's not what it is about. I
> > can't possibly know all the answers for the gui, all the best ways, but I
> > can, do and will sit and spend hours fiddling with combinations and
> > permutations or the screen (usually in QT designer) or VB,or wxPython, 
> > to see what does functionally work. At the end of the day however,
> > someone has to be able to say that from their experience, I think xyz
> > will work.
> >
> > And yes, I won't get it right all the time, yes I'll balls some things
> > up, yes others will chip in and correct the process, yes in version nnn
> > from users experience and combined wishes stuff will be changed,  but
> > someone needs the hand on the gui-design tiller, and that was what I was
> > designated to do in the first place.
> >
> > Regards
> >
> > richard
> >
> > On Fri, 16 Jul 2004 02:13 pm, you wrote:
> > > On Jul 15, 2004, at 4:44 PM, Richard Terry wrote:
> > > > I wish somewhere in your hearts you could put some trust in my
> > > > abilities to
> > > > make things functional and just, even for a period of say two months,
> > > > follow
> > > > my instructions blindly regarding the gui,  and just do what I say to
> > > > improve
> > > > the look of the gui and its functionality
> > >
> > > This has come up more than once and maybe it is in the interest of the
> > > project to address it now, so that we either commit (say through 0.1)
> > > to let Richard drive the GUI, or to more clearly resolve why not.
> > > Warning: while 9 more paragraphs follow, most are bearably short :-)
> > >
> > > I can agree that during any one iteration (like getting to 0.1) it
> > > behooves us to work consistently under one GUI plan.
> > >
> > > Only a few have commented, but most have so far seemed supportive of
> > > the Richard/Ian SOAP widget and where not, maybe only through
> > > misunderstanding.
> > >
> > > I think we should give it a "go" . We may just need to be mindful of
> > > the following:
> > >
> > > It is possible that there may be some uneasiness / unhappiness about
> > > the choices along the way!
> > >
> > > a) even the "technical" people may not be able to see their way fully
> > > to the end of a 0.1 GUI implementation until it has been tried, i.e. to
> > > know in advance whether everything (maybe some key things) that Richard
> > > wants, or will want, will be deliverable. However, though we cannot
> > > predict these in advance, we can discover them on the way, and likely
> > > in such event we can find acceptable (if not ideal) solutions.
> > >
> > > b) part of any uneasiness might derive from intermittent limitation on
> > > Richard's part, in either time or in his ability to convey by email
> > > particular reasonings, but maybe it is only through a successful
> > > implementation that the reasoning and the "pros" -- which presumably
> > > may outweigh any "cons" -- can be better experienced and thus
> > > understood. And if it proves to be broken (not able to be made to work
> > > satisfactorily) then at least Richard can know it wasn't for lack of
> > > most people having given it a real chance.
> > >
> > > NB on b) I still have trouble with the idea of an editing area in which
> > > arrow keys permit the insertion point to travel anywhere within the
> > > entire area, and the Enter key will start a new line *provided the
> > > insertion point is in mid-text*, yet in the face of an insertion point
> > > begging to receive more text input, or pending a request for a new
> > > line, the Enter key will otherwise behave quite unconventionally and
> > > IGNORE the insertion point, NOT exit saving the SOAP note, but JUMP
> > > somewhere. And yet, if we give Richard the nod, I will accord him the
> > > responsibility of devising a consistent and satisfactory system, if not
> > > up front, then fixed in due course. Ordinarily I and others would think
> > > we should still post any worries or concerns, trusting Richard will at
> > > least note them, and give them due consideration before disregarding,
> > > if that is his decision. Richard would need to advise whether "blindly"
> > > means no questions, or whether alternative views are welcome along the
> > > way, maybe sent to him and Ian privately, but without them having to
> > > feel the need to explain or defend everything along the way.
> > >
> > > c) it is pretty clear to me that Richard would not be asking other
> > > people to take a lead in the coding if he were able to do most of it
> > > (or even lead it) himself. Therefore a deliberate mindset would be
> > > needed by all during this effort, if I can reference the John Belushi
> > > film "Animal House", to NOT listen to the devil on the left shoulder
> > > saying "where does Richard get off, thinking he is the master and we
> > > are the slave" and instead think "let's cut him however much slack I/we
> > > can". Any pessimists can even reserve the right to expect to be able to
> > > say (silently I hope) "I told you so", but hopefully with a *sliver* of
> > > willingness to be proven wrong. Flames tolerated, though my intent was
> > > to dampen rather than fan any.
> > >
> > > Sorry for preaching, especially without a license, let alone training,
> > > but can we achieve a consensus?
> >
> > _______________________________________________
> > Gnumed-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnumed-devel