Re: Pure GTK vs Gnome

[Iago Rubio <iago iagorubio net>]

Hi Christoper,

On Sun, 2004-04-04 at 12:29, Christopher Fairbairn wrote:
> Hi,
>
> I thought I would combine some replies to save the amount of traffic
> generated.

[ snip ]

> 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).

Being this your case, you can use Gnome libraries as the porting to
Win32 will be easy in a sort future.

> 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 

You can safely use libgnomecanvas. I was in a mistake when I stated
about it's dependencies.

As Murray pointed, libgnomecanvas have no dependencies with Gnome so you
can easily port it to Win32.

Sorry for this mistake.

> 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.

You should avoid the over work if the requeriments of your application
does not fit in GtkDrawingArea capabilities.

> 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?

The application data files used be stored in the
$prefix/share/$app_name.

$prefix is a configurable location, selected at install time and use to
be: 

/usr
/usr/local
/opt
...

So if your application is called "dong" it's configuration files should
be in one of:

/usr/share/dong
/usr/local/share/dong
/opt/dong
...

User configuration files used to be in his home directory, usually in a
hidden folder with the application's name:

/home/me/.dong as example

The files in the application data folder are usually not writabble by
the user, but the sysadmins.

To override configuration variables, you can place them in a global 
configuration file, and use the user's configuration variables stored in
his home dir, only if they're not defined in the global configuration. 

As easy as to read first the user's config, and then the global config
overriding all that's defined there.



Best regards
-- 
ÂÂÂÂÂ NO ME USES !!!!!!!
Solo para correo interno