Re: Pure GTK vs Gnome

[Christopher Fairbairn <ckf13 student canterbury ac nz>]

Hi,

I thought I would combine some replies to save the amount of traffic
generated.

On Sun, 2004-04-04 at 21:10, Murray Cumming wrote:
> You should also try to use libglade on Windows. It works and it's useful
> and it doesn't need the rest of GNOME either.

Yes I am intending to use libglade and is another example of where
packages can have Gnome specific functionality but doesn't force the
usage of the entire Gnome architecture.

On Sun, 2004-04-04 at 21:03, Iago Rubio wrote: 
> I'm just asking a question from a Win32 developer, who wants to know if
> it's easier to port applications to his work platform using pure Gtk or
> using Gnome libs.
>
> ...... stuff removed ......
>
> My recommendations in this thread must be taken into account only by 
> commercial developers ( as Christoph ) that wants to take a try in their
> jobs with Gtk on Win32 systems.
>
> As you can see, this kind of people can't tell their bosses: "Well we
> must port those huge libraries, but it will be a great help to the OSS
> community", or "Yes we can use Gnome in our propietary program, I'm sure
> that in the future the libraries will be ported".
>
> For any other developer, I recommend to use Gnome libs, if they're
> required by his job.

Perhaps I should clarify exactly what my position is and what I'm
getting organised/thinking about doing.

When I am working for my employer I mostly develop Win32 code for
desktop and PDA applications. So most of my experience with GUI
development tools, and best practices (such as configuration mechanisms,
graphics libraries etc) is under this platform.

I personally utilise an application which was last updated in 1985. At
present I utilise it under dosemu. However with recent times this
program is starting to really show it's age and various aspects of it
(printing etc) is starting to become a real pain.

I have written various little utilities to manipulate the files
generated by this application, but I'm now thinking it would be a fun
personal project to totally update this application to a GTK+ based
application.

As such my interests in this project are personal and have nothing to do
with my employer. My concern/careful treading at this early stage with
figuring out how to maintain the possibility of porting to Win32
eventually is that the majority of people that use similar products are
rather tied to the Windows platform. Although I (personally) have no
problem having a program tied to a Unix style platform, it does rather
limit the usability of the application by many typical users of this
type of application (where people typically also use commercial software
worth $1000's of dollars per year in licensing which wine etc can't run
easily).

On Sun, 2004-04-04 at 08:46, John K Luebs wrote: 
> > Is not enought gtkdrawingarea, for your requeriments ?
> > http://developer.gnome.org/doc/API/2.0/gtk/GtkDrawingArea.html
> > http://developer.gnome.org/doc/API/2.0/gdk/gdk-Drawing-Primitives.html#GdkDrawable
>
> GtkDrawingArea and gnomecanvas are not the comparable at all;
> one amounts to GTK wrapper around an OS Window, and the latter is
> a high level drawing object kit.
> Using the former when you need the latter requires you to reimplement the
> functionality of the latter anyways. Seems pointless to me.

gnomecanvas defiantly makes things a heck of a lot more easier in my
instance (at least with a lot less manual coding). I've written a little
test app (in Perl) which parses the files made by the old DOS
application and renders them into a gnome canvas instance.

The advantages of gnomecanvas are being able to attach events to
individual shapes/objects drawn such as to allow dragging/resizing them
etc. Being able to group them and control visibility etc through the
single root "group" object.

Although obviously none of those things are impossible with using
gtkdrawingarea, using gnome canvas defiantly makes it a lot
easier/quicker to develop code to do similar 

Using GtkDrawingArea is similiar to using GDI or GDI+ under windows.
Where most of that additional functionality of user interface
interaction, clicking, moving, hiding elements etc has to be personally
implemented.

On Sun, 2004-04-04 at 07:12, Iago Rubio wrote: 
> Most people store the configuration data in xml and read it with libxml2
> or expat, that's highly portable.
>
> Sounds rude, but it's easier that I seems to be (even easier than read
> it from text).

This is where most of my difficulty in deciding how I should approach
development is situated.

Under "best practices" in a Win32 environment you would be rather
shunned if you suggested storage of configuration information in an XML
file.

In Win32 the suggest way is via the windows registry. Why, when a XML
file could store excatly the same information and be just as flexible?

Well it comes down to system administration issues etc. Using the
windows registry or similar technology allows system administrators (in
properly designed applications) to "lock down" configuration options
etc. For example to disallow end users from changing a given
configuration setting. It also allow remote administration, i.e.
configuring settings on 20 desktops from one remote machine.

Under Gnome GConf is being pushed as a similar technology with similar
system administrator aims in mind.

Using your own mechanisms for functionality such as configuration
options brings up lots of issues. For instance, where do you store the
files? How do you allow system administrators to make global overrides
of user configuration options?

On Sun, 2004-04-04 at 14:24, Darryl Luff wrote: 
> I think that if portability is an issue (and it usually is) you first 
> need to separate the program logic from the UI code. Then you or others 
> can create GUI's for whatever framework you (or they) want without 
> fiddling with the main app code.

Yes I think you have hit the nail on the head here, and this is a
similar conclusion to what I've been reaching myself.

At the moment I have a C++ class library which parses and allows
manipulation of the file contents made by this legacy application I am
thinking of replacing.

It would seem the best way to make a program nice and easily portable,
while looking as "native" as possible to each platform would be as you
suggest.

I could have a configuration base class, and then just have one derived
class using GConf for Gnome, or the windows registry for Win32, or
custom XML file etc. Were ever possible (library availability etc) I
could attempt to use the same implementation across all supported
targets and only split into platform dependant implementations where it
was required to gain compilation (missing libraries) or for native look
and feel (configuration mechanisms).

For most of my implementation "basic" GTK+ will perform everything that
I require with maximum possibility of portability across platforms.

Thanks,
Christopher Fairbairn