gnupic: Thread: gpsim development

For the last 8 months or so, Ralf Forsberg has been an integral developer
for gpsim. In fact, over 90% of the gui code has been due to his efforts.
He and I regularly exchange messages and would like to include others in
on the discussions we've been having.

First question:
The bandwidth on this list has been extremely low. Would anyone object to
gpsim development issues being discussed here? And if so, would someone
else care to host another mailing list?


First Issue:

Ralf is working on a feature that will save the window states. Essentially
he's creating an rc/session manager. We've shot a few ideas back and forth
and we both like an approach that is implemented in eXode (
http://simplicity.net/exode/ ), the enhanced X open desktop. Ralf cites an
example from eXdbm, the database library for eXode.

The file format looks like this:

# I am a comment for Variable
Variable = 12

FORMAT_LIST {
   TAR_GZ {
    Description = "gzipped tar archive"
    Magic = "\\032\\341"
    Pattern = "*.tar.gz:*.tgz:*_tar.gz"
    ViewCommand = "%DEFAULT"
    EditCommand = "eXtar"
  }

  IMAGE {
    Description = "graphic image"
    Magic = "%NONE"
    Pattern = "*.gif":"*.jpg":"*.tga"
    ViewCommand = "%DEFAULT"
    EditCommand = "gimp"
  }
}


-------
The idea is that we'll put the window specific information (e.g. size and
location) into a structure formatted as shown above. Then we'll use the
eXdbm code to parse the file. We're not saying that eXdbm will be
required. Chances are that Ralf will borrow the necessary files and make
them part of gpsim's distribution.

Comments?

Scott

Good idea, Scott.  Have the discussions on this list. This is likely to bring
some of us lurkers out.

Mal Goris
__________________________________________________
CSC Australia
Ph: 02 9901 1324    Fax: 02 9901 1555    Email: ####@####.####


####@####.#### on 07/01/2000 02:16:55

To:   ####@####.####
cc:    (bcc: Mal Goris/AUST/CSC)
Subject:  gpsim development





First question:
The bandwidth on this list has been extremely low. Would anyone object to
gpsim development issues being discussed here? And if so, would someone
else care to host another mailing list?

Have you considered using XML?
 - it's becoming popular http:www.w3.com/XML
 - libxml ftp://ftp.gnome.org/pub/GNOME/stable/sources/libxml/ can parse/save it very easily 
 - xml files can be edited with a text editor 
 - may be viewable with some html/xml viewers   
 - it's used in glade as one example (of many)
 - it should do everything that you want
 - the author of libxml is very active and helpful


Your screen position code could be placed in a "settings.xml" file which could
store all the settings for gpsim. It would look like this:

<?xml version="1.0"?>
<GPSIM Title="GPSIM Settings">
  <ScreenPositions>
    <Screen1>
      <x>100</x>
      <y>200</y>
    </Screen1>
    <Screen2>
      <x>50</x>
      <y>75</y>
    </Screen2>
  </ScreenPositions>
</GPSIM>


At your code initialization you could read the settings file then when you
close your app you could write the settings file back to disk.

See my very preliminary code at:
http://webhome.idirect.com/~tekatch/anthony/picrad/index.html


> First Issue:
> 
> Ralf is working on a feature that will save the window states. Essentially
> he's creating an rc/session manager. We've shot a few ideas back and forth
> and we both like an approach that is implemented in eXode (
> http://simplicity.net/exode/ ), the enhanced X open desktop. Ralf cites an
> example from eXdbm, the database library for eXode.
> 
> The file format looks like this:
> 
> # I am a comment for Variable
> Variable = 12
> 
> FORMAT_LIST {
>    TAR_GZ {
>     Description = "gzipped tar archive"
>     Magic = "\\032\\341"
>     Pattern = "*.tar.gz:*.tgz:*_tar.gz"
>     ViewCommand = "%DEFAULT"
>     EditCommand = "eXtar"
>   }
> 
>   IMAGE {
>     Description = "graphic image"
>     Magic = "%NONE"
>     Pattern = "*.gif":"*.jpg":"*.tga"
>     ViewCommand = "%DEFAULT"
>     EditCommand = "gimp"
>   }
> }
> 
> 
> -------
> The idea is that we'll put the window specific information (e.g. size and
> location) into a structure formatted as shown above. Then we'll use the
> eXdbm code to parse the file. We're not saying that eXdbm will be
> required. Chances are that Ralf will borrow the necessary files and make
> them part of gpsim's distribution.
> 
> Comments?
> 
> Scott
> 
> 



Anthony

No objection to use of this list for gpsim development.

-- 
James Cameron   ####@####.####   http://quozl.us.netrek.org/

On Fri, 07 Jan 2000, Anthony Tekatch wrote:

>Have you considered using XML?

I haven't understood what XML is all about, but it is simple to
switch to libxml if it is wanted.


I have also thought about using guile since that it enable
conditional configuration (based on just about anything), and could
eventually be used to give gpsim scripting abilities.


> - it's becoming popular http:www.w3.com/XML
> - libxml ftp://ftp.gnome.org/pub/GNOME/stable/sources/libxml/ can parse/save it very easily 
> - xml files can be edited with a text editor 
> - may be viewable with some html/xml viewers   
> - it's used in glade as one example (of many)
> - it should do everything that you want
> - the author of libxml is very active and helpful
>
>
>
>Anthony
>

 / Ralf

On Thu, 6 Jan 2000, Anthony Tekatch wrote:

> Have you considered using XML?


<IDEAS>
  <OPINION 1> Not for this application I haven't. My views on XML are that
it's a compromised protocol. I'm not saying it's not useful - the ability
to dynamically define attributes for example, is extremely powerful. But
think about it's purpose for a moment. You've got two things that want to
communicate. The way in which they convey information to one another can
be done many, many different ways. <UNNECSSARY SARCASM>Each new year of
college graduates finds a "better" way. </UNNECSSARY SARCASM>XML is
currently at the top of the evolutionary protocol chain. It has the
benefit of being both machine and human readable and it's extensible.

  <SOAPBOX> However, in my very limited experience with it, I find that
the "human readable" feature not to be particularly useful. In other
words, in order for the machine to understand XML the language has to be
rigidly constructed. The verbose encapsulation shadows the information to
the point it's difficult for a human to read. An analogy would be to
browse the web and just looking at the html sources. So to make it easier
for humans to read, some kind of front end browser will be needed. The
communication sequence is thus: I have an idea, express that to my
browser, my browser converts it xml, the program with which I'm
communicating reads the xml, runs it through a parser, and finally
recieves the idea. XML is an unnecessary step in this scenario - you could
go straight from the browser to the machine. </SOAPBOX>
 </OPINION1>
</IDEAS>

XML is useful for the web (and in many other places), but inappropriate
IMO, for this application. What do others think? Is it really a moot point
since the users of gpsim will mostly not even look at this context file?
What other benefits can XML provide?  Even though I appear very negative,
I really wouldn't object to having an XML structured file.


Anthony, please don't take this personally. I'm having to deal with xml
for another application at work. I'm aware of both its strengths and
weaknesses. But like I said above, I have very limited experience and so
my opinions may be (probably are) unwarranted.

Scott

Hello Scott,


> 
> <IDEAS>
>   <OPINION 1> ............

Writing your reply in XML is classic :-) 



> Anthony, please don't take this personally. I'm having to deal with xml
> for another application at work. I'm aware of both its strengths and
> weaknesses. 

I couldn't take it personally since I have no vested interest in XML and am too
much of a novice to argue the points with you.

I chose to use XML (libxml) in my little application because the parsing and
saving code was already written and XML seemed very popular. I agree with you
about XML not being very readable but it is more readable than a binary file.

A quick glance at eXdbm suggests that you must still parse/open
(eXdbmOpenDatabase()) and save/close (eXdbmUpdateDatabase()) the file. The only
surface advantage that I can see to eXdbm is that the text database file is more
easily readable than an XML file. Also the eXdbm documentation seems a bit more
uniform and complete than libxml.

It took me a while to get used to the libxml code but I think it was worth it.


--
Anthony

On Fri, Jan 07, 2000 at 07:18:20AM -0600, Scott Dattalo wrote:
> XML is useful for the web (and in many other places), but inappropriate
> IMO, for this application. What do others think? 

I code in GTK+ as well.

If I was implementing window configuration retention or other GUI
settings for a GTK+ program, I would first try to see if a gtkrc file
would do it.  If not, then libxml would only catch my eye if the
interface calls I make are sufficiently easy to justify the dependency.

It may hurt gpsim's user base to place a dependency on libxml.

On http://quozl.us.netrek.org/gfocustimer/ my settings are recorded in
a plain text file, as a series of name value pairs.

-- 
James Cameron   ####@####.####   http://quozl.us.netrek.org/

> It may hurt gpsim's user base to place a dependency on libxml.

For the same reason it may hurt gpsim's user base to place a dependency on
xDbm. For something as simple as saving screen positions then it would be
overkill to be dependent on any third party software. 


--
Anthony

> >Have you considered using XML?
> 
> I haven't understood what XML is all about, but it is simple to
> switch to libxml if it is wanted.

I only suggested XML because I chose to use it for my application which needed
a tree based structure that had a method for editing the tree. 

Here are the cons: 
 - it is not easy to get or put variables using libxml 
 - depending on 3rd party source is not good for a few simple variables

--
Anthony