Subject: Re: Abstract dialogs.
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri Sep 29 2000 - 16:52:23 CDT
On Fri, 29 Sep 2000, Mike Nordell wrote:
> Martin Sevior wrote:
> > While I would love to able to write a dialog once for every platform and
> > leave it, I shudder to think of the amount of work this will require.
>
> I get your point, and it will be *work*. I know some of the work involved
> (been there, done that, so I have at least some experience in this area). It
> wont be fun all the time, it will be really boring sometimes, but in the end
> it will work the way it should have worked from the beginning (IMHO): Add a
> dialog and it works for *all* platforms.
I believe that you can do this Mike.
>
> [GTK details]
> > However I asume you are aware things like this...
>
> I am aware of every platform dealing *very* differently with things like
> this. I don't claim to be a "wiz" on each and every platforms GUI, but we
> have the competence needed here. I think it can (and will) be done.
> Actually, it's the only way I can see AbiWord (and later possibly AbiCalc)
> work in a reasonable way.
>
Well there are a number of other ways to do accomplish this.
1. Just use gtk dialogs since the gtk is being ported everywhere anyway.
Windows, QNX, BeOS are either completed or well advanced. The case for
doing this becomes pretty compelling once the bonobo integration is
completed. Then we get for free an advanced spreadsheet, (gnumeric),
plotting component (guppi), SVD graphics (numerous), html (mozzilla),
raster graphics (eog) and maybe gimp plus whatever makes it out of
staroffice and the whole gnome momentum. Any bonobo component can be
embedded in any other.
There are a number of disadvantages of doing this. Amongst these are:
a. We lose native look and feel. I'm not sure how much this will be a
problem since the gnome theme engine is already very versatile and for gtk
2.0 may well be able to emulate any other toolkit.
b. Slight performance loss since the gdk wrapper will have to wrap the
native widgets which we would have used anyway.
c. Political. We become absorbed into gnome. We may lose non gtk
developers.
2. We (you!) could port glade and libglade to windows and write a Windows
front end to map the glade xml file describing the GUI to MFC. I think you
would have to do something like this anyway. The advantage of this is that
XML file describing the GUI is already well defined and the gtk translator
already works. The XML file describing the interface is loaded at run time
and used by libglade to generate the gui.
3. We could adopt one of the numerous cross platform GUI's
> > As I said I can't imagine this will work so I'm interested to
> > see why you think it will.
>
> Maybe your imagination is suffering, or I have a bit more experience in this
> area? :-)
>
Sorry I should not have been so negative I meant more like: I'm really
interested to see how you will do this.
> The reasons it will (or at least I think it will):
> - No one wants to write a new dialog for each platform to every dialog added
> to AbiWord.
> - Ehhh... Isn't that enough
This is an interesting point. I find writing GUI code fun. It's the most
fun part of developing for abi. I just fire up glade and start placing
widgets where I want them. I'd be perfectly happy writing gtk front ends
for dialogs initally implemented on other platforms. As long the code
dialog was reasonabally xp.
>
> It will work. Dialogs c'tor or "init()" will take care of controls
> positioning for each platform.
> What is the real problem is how to move data
> (as in a string from an edit field, a bool from a checkbox and so on) back
> and forth between the dialog and the class(es). We will have to create
> platform independent classes for this stuff, but it won't be half as hard as
> tracking every new addition of a new dialog to AbiWird for each and every
> platform in the end I think.
>
> You're free to think it won't work, but I *know* it can be made to work.
> That's what matters to me.
>
I believe you but how long will it take?
> > As someone who has done quite a number of gtk dialog front ends I don't
> > think the the GUI code is all that hard. I can normally knock one off in
> > less than 10 hours. The HARD part of writing a dialog is getting the xp
> > backend code right.
>
> My point.
>
> > Look at Lists. 95% of the sweat in that dialog is in the backend code.
>
> My point again. That 95% should be put on the XP implemetation. After that's
> done, every platform should "just work".
One of the strengths of open source is that you attract interested
developers with specific knowledge. Getting the 95% of the work done in xp
and leaving the final 5% to people with intmate knowledge of their own
platforms seems like a good division of labour.
>
> > I love it when someone else produces a platform specific dialog. Its
> > usually a little bit of straight forward work to port it to gtk. GUI stuff
> > is easy,
>
> GUI stuff is (reasonable) easy. Platform dependent dialogs are easy. Making
> the user think of the UI as intuitive is the hard part. For us the "hard
> part" is to decide what a Dialog should do and provide.
>
> > doing the xp backend stuff is hard.
>
> And that's the part I'm willing to do, or rather the "interfaces" and design
> needed. It is hard to get it right, and I think it's needed.
>
Well Mike I certainly respect your abilities. However at the end of the
day I rather just use glade and my hard won gtk knowledge rather than
learn yet another GUI toolkit (which is what your suggestion sounds like).
Cheers
Martin
This archive was generated by hypermail 2b25 : Fri Sep 29 2000 - 16:52:32 CDT