GNOME Code Challenge

[JRS]

I was wondering if there are others out there that would like to use Glade as a GUI designer with their projects? I have used ToDoList for some time under Windows and think it's one of the best (free) task list programs around. Nothing like this exists on Linux that I have found. I think this would be be a good group project that would produce something we all can use.



Comments and suggestions welcome!

Windows 6.1 Runtime & Source attached. (no install required, just drop in a sub-dir and run)

[AIR]

Here are a couple a quick search turned up:



Taskjuggler






Openproj

[JRS]

I decided to go with Planner.

It's done with Gtk and and might help me learn a few new tricks.

Good News!

Planner is using Glade. The attached task dialog is actually running under ScriptBasic.

What might end up being the code challenge is embedding ScriptBasic in Planner. I can think of lots of ways a scripting engine embedded in a project manager might come in handy.

I think the first step is to externally script Planner. From ScriptBasic I can modify the XML project files and extend or reuse the GUI. Embedding would give me access to active projects in memory and modify/extend active forms. It should be a fun learning project either way.

[JRS]

I have given Planner a quick spin around the block and I'm thinking that this could be a nice tool for scheduling employees. (fast food to a factory shifts)

I haven't looked at the code yet but it might be fun to see if it's worth rewriting in ScriptBasic (logic) and use the existing GUI. If I were to take on the task, I would use a MySQL database rather than write/read XML files. (should be an export/import option not a default file storage means) Doing queries on a SQL database has to be easier and more efficient than with a XML flat file.

Update

There is a SQL option. (PostgreSQL)

It's written in C and would be a lot of work to convert to anything else. I still see extending Planner externally with ScriptBasic and maybe try to embed SB.

I wanted to see if I could build Planner from source on Ubuntu. It worked but what a monster to compile.

[JRS]

Here is an update on my progress of getting Planner to work with a SQL database. This is a preface to a scripting effort to follow.

What I have learned ...

• Planner supports a SQL import/export option using the Libgda GNOME-DB interface to PostgreSQL. (Gda Browser)
  
• At this time it seems only the 3.0 version of Libgda is supported (version test in Planner code causes 4.0 to fail with the compile)
• PostgreSQL is more admin intensive then using MySQL. (maybe its because I'm not up to speed with it yet. SB has a PSQL extension module  ;D )
• With a little help from AIR, I was able to recompile Planner --with-database support. (not sure why any DB can't be used via Libgda and psql seems required - more on this later)
• I have seen references to Lua in the Planner source so embedded scripting may be available already and SB may be to late to the table.

Now that I have switched to Linux, I'm trying to put together solutions for my clients using open source software and gluing it together with scripting tools. It's sort of like being hired to be Santa Claus and put a custom Christmas together as a service. (batteries and ongoing cheer available upon request)

[JRS]

I thought I was home free with using a SQL database with Planner in my last post. Trying to connect became the impossible dream.  

I found out that Planner has a Python plug-in for scripting which is much better than Lua IMO.

After spending a couple days debugging and looking at source and documentation I decided to recompile after the libgda-4.0 install and enabled the Python plug-in for good measure.

Low and behold the stubborn bastard actually connected and auto created the DB and tables as it's suppose to.  

Well, now I can start playing with the scripting side of Planner.

The GNOME project is an effort to create and provide a complete, free and easy-to-use desktop and mobile environment accessible to all users, as well as a powerful application development framework for software developers. GNOME technologies are used in millions of desktops, phones and devices around the world.

My goal with this code challenge is to bring myself (and anyone interested) up to speed with the GNOME desktop API and using it's core applications. There is a interface to Evolution (e-mail client) data server from Planner but it's experimental and I'm not that brave.

More to come ...

[JRS]

The Python plug-in for Planner was a big disappointment. I get a seg. fault trying to run the test scripts. Basically all this plug-in does is looks for a .py script in a directory and executes it when Planner starts.   I'm not sure about the user base for Planner but it seems to be maintained by a small group and until my post to the list, July was the last activity. You would think if the GNOME project took Planner under it's wing, there would be more resources thrown at it.

I think Planner could be a good candidate for a SB implantation or maybe JavaScript like UltraEdit did with their editor.

[JRS]

My issue with the Python plug-in is known bug and somehow was broken along the way. In my opinion, the Python plug-in is a kludge. The current author is migrating to a Libpeas interface for scripting and not sure if Python will still take the scripting center stage.

I have what I need to externally script Planner. ScriptBasic has had a PostgreSQL extension module for years and I might add Libgda to the GTK-Server interface for a one call does all solution.

My long term goals at this point is to start embedding ScriptBasic in GNOME applications that haven't jelled fully and see if the community might adapt to ScriptBasic as the Linux VBA.

Extending Libpeas to support ScriptBasic as a Plug-in may be a wiser choice.

libpeas is a gobject-based plugins engine, and is targetted at giving every application the chance to assume its own extensibility. It also has a set of features including, but not limited to:

    * multiple extension points
    * on demand (lazy) programming language support for C, Python and JS
    * simplicity of the API

[JRS]

I thought I would post a few interesting links about where the GNOME project is headed and what this might mean for developers and VARs.

GNOME is the ideal choice for almost any purpose:

GNOME is the desktop of choice for industry leaders like IBM, HP, and Sun. Governments in places as diverse as Kenosha, Wisconsin, in the US, Extremadura, Spain, and Beijing, China, have selected GNOME for their desktops. With a large number of users, and a wide range of vendors, you can be assured of availability and support for a long time to come.

Why Choose GNOME?

GNOME Project Site

GNOME Project Listing

Gtk 3.0 Roadmap

Looking for work?

Executive Director

The GNOME Foundation is currently recruiting an Executive Director to run and grow The GNOME Foundation and project by engaging volunteers, governments, partners, companies and independent organizations. The Executive Director will work to develop and maintain programs to further GNOME’s goals, to promote the benefits of the GNOME platform, and encourage contribution and collaboration within the GNOME ecosphere. Applicants for this job would be able to work effectively on their own, with little oversight, while possessing clear communications and persuasion skills so as to be comfortable talking about GNOME in front of large crowds at conferences, executives in boardrooms, one-on-one with heads of state, and with the GNOME volunteer community.

[JRS]

I'm starting to use the Gda database tools more. It's a bit slower than using the client APIs directly but there is always a cost for convenience.