First of all, apologies to everyone that's sent me an email or has posted a message here and hasn't gotten a reply. I've been unable to keep up with gizmod over the past 6 months or so, and as such I've had to declare the project unmaintained until the school semester is over. There's a bunch of patches and fixes waiting in the bay, and a ton of redesign ideas for gizmod three, but all of it is going to have to wait.
For now here's a repost of what I put up on the home page:
I've been getting quite a few emails about gizmod lately, and even a few patches. Thanks to everyone who's working with gizmod, and for all of your suggestions as well! Unfortunately my other life commitments (work and school) are taking up a lot of time, and I simply don't have the resources to work on gizmod right now. I can barely find time to keep up with regular email let alone answer technical questions and so forth.
Having said that I want to say that I'm still committed to improving gizmod, and I've got some great ideas for version 3, which I should be able to start on in a couple of months, after school is done for the year. First of all, the focus is going to be on ease of use, rather than extreme flexibility. I'll be going for auto-magic configuration wherever possible, but I still want the program to give users the ability to manually tweak config files if desired.
I'm contemplating a bunch of things right now, but mostly the following two are on my mind: a GUI, and dropping Python support. I'm thinking a simple GUI might be nice for creating custom keymaps. Ie, press a key, define some simple actions, or record a macro, that sort of thing. As for Python scripting. It seemed like a good idea at the time, now it just seems like overkill. Does anyone actually use the Python scripting? I'd love to hear from people if you have thoughts or suggestions for the next version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, no apologies necessary. You don't owe anybody anything... this is your project, we just happen to benefit from it!
Regarding Gizmod 3: I understand your desire to simplify, though, my personal opinion is that it would be a shame to remove the scripting support, and probably not so much easier to maintain the gui.
It's true that the v2 python configuration files were quite overwhelming... but I think that was mostly because you tried to offer us one file that DID IT ALL rather than a few simple examples. And, your python coding style was somewhat unorthodox (probably because python isn't your preferred language) which made it hard for us python folks to parse (no offense, I hope). BUT it worked! I'm using a cut-down version of your config file right now on my media pc, and it's made it so I can actually use my powermate as a volume knob.
Keeping the core in compiled code and wrapping it in a simple python-accessible API will probably actually make it EASIER to make a gui... bindings for GTK and QT and all of that are out there of course, and it means that someone besides yourself could contribute to this (a pygtk expert).
But for me, the scriptability opens up so many possibilities: once you get the events into python, you can send them over the LAN to control another box, you can integrate it into your own projects, you can pretty much do whatever. If we just have a GUI configurator, then what isn't imagined by the gui builder won't be possible.
I would also say that keeping scripting support (or more accurately, language bindings) can get you out of a lot of what you put into gizmod that might be considered "ancillary". For me, the most important feature is the powermate support. For others, no doubt they don't care about that at all.
But python (or C# or whatever) already have facility for XOSD, and making X keyboard events, and dbus, networking, and gnome-vfs, and gstreamer, and ALSA, and ...
So it seems to me that very nice simple solid event-capture-and-massage with a good API would allow us to build up whatever features we want, as a community, and hopefully not so much on your shoulders.
Excellent, thanks for your input! I appreciate everything you said, and I believe very much that you're right.
Regarding evrouter, I have actually seen (and used it), and incidentally it was the primary motivation behind gizmod. Evrouter is great, but doesn't have built in powermate support, and it wasn't flexible enough for my needs.
I was secretly hoping that people out there were using the scripting for something, because obviously I wouldn't have put it in if I didn't think it was useful. So it's nice to hear an opinion on the matter.
Here's what I'm thinking so far:
- Python scripting stays, BUT -- it needs to be muchly revamped. My python friendliness has improved a fair bit since then, but it might be nice to have some opinions on the best way to go about it from all you friendly local neighborhood python gurus.
What I'm thinking would be cool is if each device was its own separate class. I'd like the individual python files to remain small, manageable, and easy to understand. The main python script file might just consist of some imports and tests to see if a module imported then use its functionality kinda thing.
- xmms and bmp support are gone. sorry if you use them, but unless someone else wants to take over this part I'm not willing to do it. I'm probably going to create a libvisual plugin for visualizing music on the powermate's led. This means support for Amarok (which is what I'm using these days).
- The rest of the stuff, can be implemented as python modules. Like you said if people want XOSD support, it's easy enough to throw that in via python.
So here's your chance to let me know how you'd like the python API to look and work. If anyone has suggestions, thoughts, comments, etc, please let me know! I'll definitely take them into consideration.
As for the GUI bit, I'd still like to see this materialize. It might be nice to have a systray icon, or at least an app that lets non-programmers quickly define events and actions. This means a couple of things:
It would be nice if simple actions could be defined in such a way that the currently loaded python script doesn't need to be shut down and restarted. AND, it would be nice if the python scripts could be designed in such a way that both a GUI and humans can easily edit them.
Right now my initial thought process is to treat the GUI as a separate module. Have a GUI python class that will look similar to the other python modules and will have the ability to load simple events from an easy to parse configuration file (that can obviously be reloaded at will). This class will do nothing more than programmatically create event / action pairs in the main program. I'm not totally in love with the idea, as it involves a bit of redundancy, so I'm definitely open to any alternative ideas people might have.
Thanks again Feifarek for your input. If you (or anyone else out there) has opinions, please let me hear em!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the delay... I've been out of town for work for the last couple of weeks, and didn't have much time to catch up on hobby stuff.
I'm so glad that you liked my requests ;-)
My opinions on what you asked for:
1. I'm not a C programmer, so it's hard for me to say who's done a nice job on python-wrapping and API authoring. I suppose look at PyGTK and PyGstreamer or big visibile projects like that to get an idea. They're both WAY bigger than GizmoD so maybe they're not appropriate.
The Twisted project is considered to be code of high quality. I do web programming mostly, and find the Pylons project (and its support libraries) to be high-quality code.
There's so much python out there, that it seems like it should be easy to find some good examples. Perhaps the gstreamer is a good one, since it's probably media oriented and event-based. Sorry I can't be more helpful on this question.
2. as for the gui, you might have some luck looking at the wacom stuff... it has a custom control panel and deals with X input.
I would be willing to get a little more involved with the design of the API if you want... I don't know much about the guts of your code, but if you need someone to help bounce ideas off of, or to help write docs leading to requirements or whatever, I'd be game. If you'd like to talk about it off list, I'm at matt.feifarek@gmail.com.
Thanks again for GizmoD.
-- Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The idea is to keep everything as simple and modular as possible -- there (hopefully) won't be too much more in that file than you see there now (aside from a line of code or two that sends the incoming events off to other modules).
Ultimately what I'm striving for is to have the GizmodDispatcher send off events to modules based on their type. So when the script starts up it'll import all the user created python scripts it sees. Each user script will register itself and let the system know what types of events it's interested in. That way users can easily create / share config scripts -- we can hopefully even have a central script repository somewhere.
I'm also making a real effort on code documentation this time around :). Along with the internal comments in the python code, the full api will be browseable from doxygen generated documentation.
Anyway, there's not much there yet, but since I've not gotten that far it's a good time for suggestions :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Boost scares me a bit... last time I tried to use something that wanted boost, it "built" for 45 minutes and didn't actually create anything :-(. That was PythonMagick... hopefully it was pilot error.
I can't ./configure it, but I'll wait 'till you're ready to have other people poking around in here. In the meantime, I'll look at the python stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, first I had to run ./autogen.sh... which seemed to work.
Then when I run ./configure, a long chain of stuff happens, ultimately failing with this block:
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
./configure: line 19662: syntax error near unexpected token `1.33.1'
./configure: line 19662: `AX_BOOST_BASE(1.33.1)'
My configure script is almost 700K! What's up with that!?
If I DON't run autogen.sh first, I get this:
configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."
Yes, this reminds me of my other Boost experience ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right... yeah this is because you need to have the boost autoconf macros installed in order to use autogen. If you're really keen you can install them... they should be in the dependencies/m4 directory. All you need to do (usually, depending on the distro) is copy them to /usr/share/aclocal. Then you should be able to autogen.
If you don't feel like going to the trouble, no worries, just wait till I've got something ready packaged up, and ready for general consumption.
At any rate, let me know how you feel about the general design idea behind the python interface.
Thanks!
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, apologies to everyone that's sent me an email or has posted a message here and hasn't gotten a reply. I've been unable to keep up with gizmod over the past 6 months or so, and as such I've had to declare the project unmaintained until the school semester is over. There's a bunch of patches and fixes waiting in the bay, and a ton of redesign ideas for gizmod three, but all of it is going to have to wait.
For now here's a repost of what I put up on the home page:
I've been getting quite a few emails about gizmod lately, and even a few patches. Thanks to everyone who's working with gizmod, and for all of your suggestions as well! Unfortunately my other life commitments (work and school) are taking up a lot of time, and I simply don't have the resources to work on gizmod right now. I can barely find time to keep up with regular email let alone answer technical questions and so forth.
Having said that I want to say that I'm still committed to improving gizmod, and I've got some great ideas for version 3, which I should be able to start on in a couple of months, after school is done for the year. First of all, the focus is going to be on ease of use, rather than extreme flexibility. I'll be going for auto-magic configuration wherever possible, but I still want the program to give users the ability to manually tweak config files if desired.
I'm contemplating a bunch of things right now, but mostly the following two are on my mind: a GUI, and dropping Python support. I'm thinking a simple GUI might be nice for creating custom keymaps. Ie, press a key, define some simple actions, or record a macro, that sort of thing. As for Python scripting. It seemed like a good idea at the time, now it just seems like overkill. Does anyone actually use the Python scripting? I'd love to hear from people if you have thoughts or suggestions for the next version.
First, no apologies necessary. You don't owe anybody anything... this is your project, we just happen to benefit from it!
Regarding Gizmod 3: I understand your desire to simplify, though, my personal opinion is that it would be a shame to remove the scripting support, and probably not so much easier to maintain the gui.
It's true that the v2 python configuration files were quite overwhelming... but I think that was mostly because you tried to offer us one file that DID IT ALL rather than a few simple examples. And, your python coding style was somewhat unorthodox (probably because python isn't your preferred language) which made it hard for us python folks to parse (no offense, I hope). BUT it worked! I'm using a cut-down version of your config file right now on my media pc, and it's made it so I can actually use my powermate as a volume knob.
Keeping the core in compiled code and wrapping it in a simple python-accessible API will probably actually make it EASIER to make a gui... bindings for GTK and QT and all of that are out there of course, and it means that someone besides yourself could contribute to this (a pygtk expert).
But for me, the scriptability opens up so many possibilities: once you get the events into python, you can send them over the LAN to control another box, you can integrate it into your own projects, you can pretty much do whatever. If we just have a GUI configurator, then what isn't imagined by the gui builder won't be possible.
I would also say that keeping scripting support (or more accurately, language bindings) can get you out of a lot of what you put into gizmod that might be considered "ancillary". For me, the most important feature is the powermate support. For others, no doubt they don't care about that at all.
But python (or C# or whatever) already have facility for XOSD, and making X keyboard events, and dbus, networking, and gnome-vfs, and gstreamer, and ALSA, and ...
So it seems to me that very nice simple solid event-capture-and-massage with a good API would allow us to build up whatever features we want, as a community, and hopefully not so much on your shoulders.
Also, have you seen this guy's project? http://www.bedroomlan.org/~alexios/coding_evrouter.html
I've used it to get some of my mouse buttons to work under X, but it seems similar.
So, that's my 2 cents. Of course, no pressure... I remain a believer that this is your project and should follow your wishes. Thanks again for Gizmod.
Excellent, thanks for your input! I appreciate everything you said, and I believe very much that you're right.
Regarding evrouter, I have actually seen (and used it), and incidentally it was the primary motivation behind gizmod. Evrouter is great, but doesn't have built in powermate support, and it wasn't flexible enough for my needs.
I was secretly hoping that people out there were using the scripting for something, because obviously I wouldn't have put it in if I didn't think it was useful. So it's nice to hear an opinion on the matter.
Here's what I'm thinking so far:
- Python scripting stays, BUT -- it needs to be muchly revamped. My python friendliness has improved a fair bit since then, but it might be nice to have some opinions on the best way to go about it from all you friendly local neighborhood python gurus.
What I'm thinking would be cool is if each device was its own separate class. I'd like the individual python files to remain small, manageable, and easy to understand. The main python script file might just consist of some imports and tests to see if a module imported then use its functionality kinda thing.
- xmms and bmp support are gone. sorry if you use them, but unless someone else wants to take over this part I'm not willing to do it. I'm probably going to create a libvisual plugin for visualizing music on the powermate's led. This means support for Amarok (which is what I'm using these days).
- The rest of the stuff, can be implemented as python modules. Like you said if people want XOSD support, it's easy enough to throw that in via python.
So here's your chance to let me know how you'd like the python API to look and work. If anyone has suggestions, thoughts, comments, etc, please let me know! I'll definitely take them into consideration.
As for the GUI bit, I'd still like to see this materialize. It might be nice to have a systray icon, or at least an app that lets non-programmers quickly define events and actions. This means a couple of things:
It would be nice if simple actions could be defined in such a way that the currently loaded python script doesn't need to be shut down and restarted. AND, it would be nice if the python scripts could be designed in such a way that both a GUI and humans can easily edit them.
Right now my initial thought process is to treat the GUI as a separate module. Have a GUI python class that will look similar to the other python modules and will have the ability to load simple events from an easy to parse configuration file (that can obviously be reloaded at will). This class will do nothing more than programmatically create event / action pairs in the main program. I'm not totally in love with the idea, as it involves a bit of redundancy, so I'm definitely open to any alternative ideas people might have.
Thanks again Feifarek for your input. If you (or anyone else out there) has opinions, please let me hear em!
Sorry for the delay... I've been out of town for work for the last couple of weeks, and didn't have much time to catch up on hobby stuff.
I'm so glad that you liked my requests ;-)
My opinions on what you asked for:
1. I'm not a C programmer, so it's hard for me to say who's done a nice job on python-wrapping and API authoring. I suppose look at PyGTK and PyGstreamer or big visibile projects like that to get an idea. They're both WAY bigger than GizmoD so maybe they're not appropriate.
The Twisted project is considered to be code of high quality. I do web programming mostly, and find the Pylons project (and its support libraries) to be high-quality code.
There's so much python out there, that it seems like it should be easy to find some good examples. Perhaps the gstreamer is a good one, since it's probably media oriented and event-based. Sorry I can't be more helpful on this question.
2. as for the gui, you might have some luck looking at the wacom stuff... it has a custom control panel and deals with X input.
I would be willing to get a little more involved with the design of the API if you want... I don't know much about the guts of your code, but if you need someone to help bounce ideas off of, or to help write docs leading to requirements or whatever, I'd be game. If you'd like to talk about it off list, I'm at matt.feifarek@gmail.com.
Thanks again for GizmoD.
-- Matt
I've actually gotten a bit of a start on the new python api design. So far it's turning out much cleaner, and more pythonic than gizmod2. If you want you can check out the latest copy from SVN here: https://sourceforge.net/svn/?group_id=139428 or you can directly view the main config script here: http://gizmod.svn.sourceforge.net/viewvc/gizmod/gizmod3/scripts/GizmodDispatcher.py?view=markup
The idea is to keep everything as simple and modular as possible -- there (hopefully) won't be too much more in that file than you see there now (aside from a line of code or two that sends the incoming events off to other modules).
Ultimately what I'm striving for is to have the GizmodDispatcher send off events to modules based on their type. So when the script starts up it'll import all the user created python scripts it sees. Each user script will register itself and let the system know what types of events it's interested in. That way users can easily create / share config scripts -- we can hopefully even have a central script repository somewhere.
I'm also making a real effort on code documentation this time around :). Along with the internal comments in the python code, the full api will be browseable from doxygen generated documentation.
Anyway, there's not much there yet, but since I've not gotten that far it's a good time for suggestions :)
Sounds like good news.
I've checked out the svn, and will look it over.
Boost scares me a bit... last time I tried to use something that wanted boost, it "built" for 45 minutes and didn't actually create anything :-(. That was PythonMagick... hopefully it was pilot error.
I can't ./configure it, but I'll wait 'till you're ready to have other people poking around in here. In the meantime, I'll look at the python stuff.
Ahaha... boost is a bit crazy, but there's no need to fear it :). C++ without boost is like... well, it sucks :).
Just out of curiosity what's going wrong with the configure? Is it complaining about boost, or something else?
Well, first I had to run ./autogen.sh... which seemed to work.
Then when I run ./configure, a long chain of stuff happens, ultimately failing with this block:
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
./configure: line 19662: syntax error near unexpected token `1.33.1'
./configure: line 19662: `AX_BOOST_BASE(1.33.1)'
My configure script is almost 700K! What's up with that!?
If I DON't run autogen.sh first, I get this:
configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."
Yes, this reminds me of my other Boost experience ;-)
Right... yeah this is because you need to have the boost autoconf macros installed in order to use autogen. If you're really keen you can install them... they should be in the dependencies/m4 directory. All you need to do (usually, depending on the distro) is copy them to /usr/share/aclocal. Then you should be able to autogen.
If you don't feel like going to the trouble, no worries, just wait till I've got something ready packaged up, and ready for general consumption.
At any rate, let me know how you feel about the general design idea behind the python interface.
Thanks!
Tim.