dohickey-public — General talk about Dohickey

Re: [Dohickey-public] Dohickey interactive device database for Linux - ideas

[Martin O. <doc...@gm...>]

Dear Ezekiel,

Thanks for your great suggestions, a few of them have already been
implemented. Such that it's already possible to define spaces for
specification variables and such, all ratings are distro specific.

I'm looking forward to moving the website to a django based website
which would be easier to manage than the current custom perl one.

Best Regards, Martin Owens

2008/8/11 Ezekiel 33 Technical <tec...@ez...>:
> Hi Folks,
>
> I saw your web site at;
>
> http://www.dohickey-project.com
> http://dohickey.wikispaces.com/
> https://lists.sourceforge.net/lists/listinfo/dohickey-public
>
> "Dohickey is a client / server application for managing hardware
> information. Using built-in Ubuntu services to detect the hardware in
> your system it will make a request to the server for any available
> information about each piece of hardware."
>
> This looks great.
>
> several Ideas which you may find interesting;
>
> 1) Involve the Hardware Manufacturers, suppliers and distributors.
> A number of these could be contacted directly.
> Manufacturers could join by visiting the website.
> The word could go out via email, forums, chat-rooms, eZines, and users
> can post notices on their own web sites.
> All Linux Distros could be invited to help get people involved (users,
> and hardware suppliers).
>
> The manufactures could be free to "participate" to what ever degree of
> involvement they want.
> This could range from not bothering at all, getting listed as a
> manufacturer - and still not bothering - if you want info then you'd
> have to find out yourself, through to listing their models, what
> software utilities may/do work with them, testing verifications/tests
> they've done, through to full formal support including installation and
> full manual.
>
> 2) Linux Variants.
> Enable the grouping of data based on the breed of Linux Distro and version.
>
> 3) Performance specs.
> Each piece of hardware tend s to have the performance specifications
> that are used for comparing one device against another.
> Allow the user/manufacturer to specify the/new specification parameters
> and assign values.
> For example for a hard drive.
> Assign "parameters";
> read speed
> seek time
> Assign a "calculated performance parameter";
> User can create a formula to estimate the performance when being used in
> certain ways.
>
> 4) Able to enter performance specs for "combinations" of hardware.
> Sometimes some particular models of one device are found to work better
> than other when in combination with a particular different device.
>  This may also involve some software tweaking, so there would need to
> be room for additional such comments.
> This is particularly handy if people have built some test boxes, and
> found combo that work well for given tasks. Other people could look up
> their desired tasks, and pick combo that deliver good price performance.
> Tasks might include multimedia, entertainment centre, server, gaming
> machine, Desktop Publishing, etc.
>
> 5) Which software works well with which hardware.
>
> 6) Links to further help sites/resources/downloads
>
>
> This kind of information would grow as it gets added to.
> So there will always be holes in the info.
> How ever it could very quickly become a good place to start for several
> purposes.
> This could be a very handy tool to have available on the desktop and/or
> on the system help menu.
>
> Thank you.
> Yours
> Tree
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Dohickey-public mailing list
> Doh...@li...
> https://lists.sourceforge.net/lists/listinfo/dohickey-public
>

[Dohickey-public] Dohickey interactive device database for Linux - ideas

[Ezekiel 33 T. <tec...@ez...>]

Hi Folks,

I saw your web site at;

http://www.dohickey-project.com
http://dohickey.wikispaces.com/
https://lists.sourceforge.net/lists/listinfo/dohickey-public

"Dohickey is a client / server application for managing hardware 
information. Using built-in Ubuntu services to detect the hardware in 
your system it will make a request to the server for any available 
information about each piece of hardware."

This looks great.

several Ideas which you may find interesting;

1) Involve the Hardware Manufacturers, suppliers and distributors.
A number of these could be contacted directly.
Manufacturers could join by visiting the website.
The word could go out via email, forums, chat-rooms, eZines, and users 
can post notices on their own web sites.
All Linux Distros could be invited to help get people involved (users, 
and hardware suppliers).

The manufactures could be free to "participate" to what ever degree of 
involvement they want.
This could range from not bothering at all, getting listed as a 
manufacturer - and still not bothering - if you want info then you'd 
have to find out yourself, through to listing their models, what 
software utilities may/do work with them, testing verifications/tests 
they've done, through to full formal support including installation and 
full manual.

2) Linux Variants.
Enable the grouping of data based on the breed of Linux Distro and version.

3) Performance specs.
Each piece of hardware tend s to have the performance specifications 
that are used for comparing one device against another.
Allow the user/manufacturer to specify the/new specification parameters 
and assign values.
For example for a hard drive.
Assign "parameters";
read speed
seek time
Assign a "calculated performance parameter";
User can create a formula to estimate the performance when being used in 
certain ways.

4) Able to enter performance specs for "combinations" of hardware.
Sometimes some particular models of one device are found to work better 
than other when in combination with a particular different device.
  This may also involve some software tweaking, so there would need to 
be room for additional such comments.
This is particularly handy if people have built some test boxes, and 
found combo that work well for given tasks. Other people could look up 
their desired tasks, and pick combo that deliver good price performance.
Tasks might include multimedia, entertainment centre, server, gaming 
machine, Desktop Publishing, etc.

5) Which software works well with which hardware.

6) Links to further help sites/resources/downloads


This kind of information would grow as it gets added to.
So there will always be holes in the info.
How ever it could very quickly become a good place to start for several 
purposes.
This could be a very handy tool to have available on the desktop and/or 
on the system help menu.

Thank you.
Yours
Tree

[Dohickey-public] Update of the Device Database

[<2i...@ar...>]

Hello,
I would like to know, when the sent informations will appear on the 
Device Database. I was searching for my sent data about my Laptop and my 
Desktop, but could not find them. The information in the Database 
appears for me to be same as last week.
I switched the server address in the client to dohickey.parsed.net and 
got the message "Done". It seems that everything was sent correctly.

Thank you very much and
best regards, Ingo

[Dohickey-public] For how long are the sended files approx. in the queue?

[<2i...@ar...>]

Hi!
I have sended two reports (one Laptop and one desktop) and wanted to 
have a look at them on the database server. Of course it takes some time 
until they are shown in the database.
What do you think is the approximate time in the queue until they are 
integrated into the database?
I got the message back that "the queue is not cleared" and do not really 
understand what that means. Is the queue full and no more reports are 
accepted or does it just mean, that the report is still waiting for the 
o.k. to get through?

If there is a need to translate the programme into German, I could do 
it. I guess it should be understood for German people, because there are 
not so many english words used. But if you would like it, I would do it, 
if it just means to change the English sentences into German. I can't 
code, sorry.

Best regards, Ingo

Re: [Dohickey-public] ubuntu-brainstorm

[Martin O. <doc...@gm...>]

Hello there,

Thank you so much for pushing the project, I've been working on it for
over 2 years now and it's been so slow because of the lack of
community involvement. But I'm hoping this will change soon.

Work continues on the server side at the moment. and we have a
launchpad project set up to collect bugs from ubuntu users:
https://launchpad.net/dohickey

Someone also complained about my bad explinations as being the
problem, and yet finding people who are good at writing and explaining
to help is more difficult than it should be.

Thank you again for your help, we can do better I'm sure of it.

Best Regards, Martin Owens

On 02/03/2008, 2i...@ar... <2i...@ar...> wrote:
> Hello!
>  I suggested the dohickey-client for ubuntu-brainstorm, because the
>  programme is just great and easy to use.
>  http://brainstorm.ubuntu.com/idea/2374/
>
>  I also mentioned it at a German ubuntu-forum and the feedback was just
>  very good. http://forum.ubuntuusers.de/topic/156270/
>
>  Maybe you would like to give a comment at ubuntu-brainstorm?
>  I would appreciate it a lot.
>
>  Thank you very much for your work!
>  It is kind of sad, that it is yet quite unknown. But this could be changed.
>
>  Best wishes, Ingo
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Dohickey-public mailing list
>  Doh...@li...
>  https://lists.sourceforge.net/lists/listinfo/dohickey-public
>

[Dohickey-public] ubuntu-brainstorm

[<2i...@ar...>]

Hello!
I suggested the dohickey-client for ubuntu-brainstorm, because the 
programme is just great and easy to use.
http://brainstorm.ubuntu.com/idea/2374/

I also mentioned it at a German ubuntu-forum and the feedback was just 
very good. http://forum.ubuntuusers.de/topic/156270/

Maybe you would like to give a comment at ubuntu-brainstorm?
I would appreciate it a lot.

Thank you very much for your work!
It is kind of sad, that it is yet quite unknown. But this could be changed.

Best wishes, Ingo

[Dohickey-public] Dohickey 0.7 Release

[Martin O. <doc...@gm...>]

Hello Everyone,

OK I've finally decided to release 0.7, I should have done this a long
time ago and broke the "release early, release often" philosophy.

Files: https://sourceforge.net/project/showfiles.php?group_id=177020&release_id=575534
ChangeLog: https://sourceforge.net/project/shownotes.php?release_id=575534

This release comes with a couple of exciting elements, the cpu and ram
items add extra bulk to the hardware view. The view modes allow for
you to specify what ever mode you feel most comfortable working in.
And the drivers section will now tell you what kind of drivers are
being used by that device.

The website integration has been going well too, we're working on
standardising all the packages for the server side so it can be
installed very easily in future. But we have a working demo server at
http://dohickey.parsed.net/ The one at dohickey-project.com will not
be able to be updated as dream host doesn't allow us to install Lucene
text indexing for the search features. The server side now boasts some
nice browsing and searching screens and you can submit your hardware
data as a test of the client to this site also, just configure it in
the option menu.

To come in the future (we hope) is to send the driver information to
the server in a meaningful way, we hope to create a link between
hardware as identified and the drivers they use; We're then going to
link that to the development of those drivers and then on to have a
button which reports problems with a particular piece of hardware. The
end goal is to have the kernel, cups, sane (whoever) guys aware of end
user problems by removing the glut of barriers that people have in
communicating in the same language and being able to report the
correct metrics. We'd also like to work with Canonical and Dell to
develop a system of reporting failures in hardware systems to ease
support.

Big thanks go to Aaron (guinea-pig), Mindfulgeek and ubuntu-ma and my
wife for putting up with my obsession. :-D

All bugs should be reported here:
https://sourceforge.net/tracker/?group_id=177020&atid=879565 or
emailed to me personally doc...@gm...

Wiki Docs: http://dohickey.wikispaces.com/

[Dohickey-public] Dohickey 0.7: Testers needed and news

[Martin O. <doc...@gm...>]

Hello everyone,

The new 0.7 beta dohickey client is almost ready to release.

The good news is that we have some server space at MIT which we can
use to host the services that need Lucene search indexing (searching
and browsing); When this new site is set up correctly, we will be able
to release 0.7 and get some solid testing and hopefully the
submissions can begin and then I will call upon those who want to
administer the data to register once more.

The other news is that I just this morning finished working out all
the problems with the Lucene Prefabrication modules; that is, the
extensions to the base classes that make objects so damn easy can now
be indexed upon object creation and searched with the use of a special
set case. I've worked on the html some what too so we now have
browsing and searching all working lovely (on my home server).

Best Regards, Martin Owens

Re: [Dohickey-public] Dohickey and Smolt

[Martin O. <doc...@gm...>]

Thanks for getting back to me so quickly Mike!...

On 11/07/07, Mike McGrath <mmc...@re...> wrote:
>
> Sure thing.  There's a lot of people working on these sorts of systems
> right now it seems :).

It does seem the time for solving this little puzzle and from personal
experience it doesn't seem easy once you get into the meat of sorting
out the problems. although It seems to depend on what kind of results
your after as I'll try and explain:

> If you're interested smolt does work on ubuntu
> already so you should be able to download it and see how I'm grabbing my
> info and such.  I've not tested the server side on Ubuntu yet.  The
> biggest problem I've had is determining what stuff to store.  smolt
> relies on hal and I'm basically dumping everything to the database.  If
> there's a manufacturer and device ID I store by that if not I just store
> what hal dumps.  I may stop doing that soon because its unclear exactly
> how useful it is.  (for example PC Speaker)

OK first thing, hal lists many useless things to a hardware program,
the scope of the design for dohickey is such that any device without a
reliable typeId (bus:manufacturerId:productId) can't be effectively
used; so I either compensate with generic data or filter those things
out completely until I can figure out how to stabilise the ids. I use
a combination of HAL data and DMI/bios data to format a 3 tier data
model:

Computer > Hardware > Device

Because hal only lists devices it's often very lazy about how the
relationships between devices work; it's generally trustworthy for
usb, firewire is unpredictable because of missing id's but pci is a
complete mess, you can't tell what is plunged in where, how, if it's
AGP, PCI-E, CardBus or even if it's a chipset on the motherboard. this
is where dmidecode comes in to fill in all the information about the
computer tier (mostly for use with prefab computers and laptops) the
motherboard, including a pci slots list, memory and processor
information including empty slots of all kinds (a future feature is to
advise on upgrades), chipsets are relegated children on the
motherboard, physically plugged in pci cards are separated out and
their bus is modified based on parent data.

With the data it's self I store the hal and dmi data under a raw
structure, and then a further processed structure stores what it ends
up as once it's been filtered. the client can take advantage of either
the local computer, stored raw data or stored processed data; it can
also send the local computer xml file to the server via http...

> Smolt's server side is based on turbogears.  It's a self contained piece
> called 'smoon'.  Ultimately it can be used as an inventory management
> system for the enterprise though I don't know of many actually using it
> for that yet.

Unfortunately I was unable to find anything that suited what I wanted
to do, this server is perl based and contains your usual; the client
communicates (requests for updates and sending new information)
through http, no data apart from ratings are automaticly accepted and
it's just queued in a audit table for any admin to claim and merge.

Once the data for specific hardware id had been updated, all people
with that hardware should get the new version when they next run the
client; I've taken to allowing images of the physical hardware in the
profiles so I can make the client look a bit more classy.

> One thing I've been meaning to do is make all communication happen over
> xmlrpc.  If we could come up with an agreed upon format then, in theory,
> our clients could submit to both.  I'd be happy to make changes to smolt
> if you want, its mostly just a matter of -ETIME.

The xmlrpc does sound interesting, The formats stuff is listed as the following:

 * Profile - XML file describing a single computer/hardware/device id,
a flat hash of values for the main data with a list of notes (for
anomalies and advice), server ratings, local ratings and a couple of
future spaces for directives (such as a list of possible
sub-selection)
 * Fields - XML file which is a hierarchical structure describing all
fields possible in any profile data section, field availability is
selected on data pathing the structure.
 * Computer - XML file which describes all the hardware in a computer,
as well as raw data gathered from hal and dmidecode, loadable into the
client and possible to use for statistics if you collect and store
many of them and create the right kind of supporting tools.

What are your thoughts on the likely collabrative path? I'm about to
collaps into my bed right now, but If you want to try out the dohickey
client you'll need dmidecode, python-gtk-html2 (I believe some kind of
'special' python support package on RedHat and SuSE) and hal. let me
know if your able to run it or if you have problems. I'll plan on
diving into your code when I wake up later.

Thanks again Mike, Best Regards

Martin Owens

Re: [Dohickey-public] Dohickey and Smolt

[Mike M. <mmc...@re...>]

Martin Owens wrote:
> Dear Mike McGrath,
>
> I understand you are working on a project called Smolt, a hardware
> profiler using HAL, a way to get hardware information from users and
> various other features....
>
> Well I've been working on dohickey since last year, basically the same
> thing written from the perspective of Ubuntu (dohickey-project.com)
> the idea is to combine hardware profiles, ratings, computer profile
> statistics and online server side searches as well as a snazy gui tool
> (python) which detects the hardware and gives information to users in
> a nice way.
>
> I was wondering if there is a way we can collaberate, one of the
> problems I've found working on Dohickey is a lack of hardware to test
> against; to this end I asked the community to run various scripts that
> got me dmi and hal dumps; in effect I have 500 computers to test
> against (I created various support scripts that churn the sata into
> xml files so you can load them in the client)
>
> The other problem is that as a developer of 1 working on this project
> I've had very few people who I can effectively bounce ideas off of;
> I've figured out how to stream line the detection and abstract it;
> including creating various xml formats for the profiles, types etc;
> but without peer review it's difficult to validate and time consuming
> to move forwards.
>
> I'm currently working on the server side (perl based) which allows
> admins to merge the submitted data back to the main repository in a
> structured way. (also the field definitions) I'm collecting ratings
> and have search all worked out. just a slow pace in getting everything
> finished as I'm sure you know.
>
> Obviously we're slightly different in that I'm unemployed and your
> working for RedHat, but I would still be happy to bounce ideas around
> and see if our goals are similar and what formats we can share and
> ideas we can incorporate into our two projects.

Sure thing.  There's a lot of people working on these sorts of systems 
right now it seems :).  If you're interested smolt does work on ubuntu 
already so you should be able to download it and see how I'm grabbing my 
info and such.  I've not tested the server side on Ubuntu yet.  The 
biggest problem I've had is determining what stuff to store.  smolt 
relies on hal and I'm basically dumping everything to the database.  If 
there's a manufacturer and device ID I store by that if not I just store 
what hal dumps.  I may stop doing that soon because its unclear exactly 
how useful it is.  (for example PC Speaker)

Smolt's server side is based on turbogears.  It's a self contained piece 
called 'smoon'.  Ultimately it can be used as an inventory management 
system for the enterprise though I don't know of many actually using it 
for that yet.

One thing I've been meaning to do is make all communication happen over 
xmlrpc.  If we could come up with an agreed upon format then, in theory, 
our clients could submit to both.  I'd be happy to make changes to smolt 
if you want, its mostly just a matter of -ETIME.

    -Mike

[Dohickey-public] Dohickey and Smolt

[Martin O. <doc...@gm...>]

Dear Mike McGrath,

I understand you are working on a project called Smolt, a hardware
profiler using HAL, a way to get hardware information from users and
various other features....

Well I've been working on dohickey since last year, basically the same
thing written from the perspective of Ubuntu (dohickey-project.com)
the idea is to combine hardware profiles, ratings, computer profile
statistics and online server side searches as well as a snazy gui tool
(python) which detects the hardware and gives information to users in
a nice way.

I was wondering if there is a way we can collaberate, one of the
problems I've found working on Dohickey is a lack of hardware to test
against; to this end I asked the community to run various scripts that
got me dmi and hal dumps; in effect I have 500 computers to test
against (I created various support scripts that churn the sata into
xml files so you can load them in the client)

The other problem is that as a developer of 1 working on this project
I've had very few people who I can effectively bounce ideas off of;
I've figured out how to stream line the detection and abstract it;
including creating various xml formats for the profiles, types etc;
but without peer review it's difficult to validate and time consuming
to move forwards.

I'm currently working on the server side (perl based) which allows
admins to merge the submitted data back to the main repository in a
structured way. (also the field definitions) I'm collecting ratings
and have search all worked out. just a slow pace in getting everything
finished as I'm sure you know.

Obviously we're slightly different in that I'm unemployed and your
working for RedHat, but I would still be happy to bounce ideas around
and see if our goals are similar and what formats we can share and
ideas we can incorporate into our two projects.

Let me know,

Best Regards, Martin Owens (Dohickey Project)

Re: [Dohickey-public] Moving Forwards (server-side)

[Martin O. <doc...@gm...>]

This post was sent to me but it should be on the mailing list.

>> Now that we have an abstract vision of what
>> the website could look like, and have received
>> input from others, I am guessing it would be
>> appropriate to put the pen to paper, and think in
>> concrete. The ideas are quite simple to put
>> forward, but it is far more difficult to actually
>> implement them.

You have to remember that I've been developing the server side for
over a year in perl and a version is even hosted at dohickey-project
but my priorities were to get the client and server talking over http
which now works and I'm doing the admin side that calls for being able
to select the parts that should be accepted and at the moment it's
taking up much of my time.

>> The foremost mistake that I foresee is coming
>> to a certain conclusion, building on it, and then
>> regretting a step or two. This has frequently
>> happened to me while creating websites. I would
>> create a website, become displeased with one
>> thing or another, and start from scratch. I hope
>> this type of problem could be averted.

I need the front side website html, I can create templates out of the
html if you were to create the designs that you feel would be good for
user interaction. this would push the progress much further to getting
it done.

>> Furthermore, are there any technical ideas you
>> have in mind? It is possible you are better off
>> with one language or another (HTML, PHP, etc.),
>> and you may want to proceed with one of these.

Perl server, python client. MySQL database currently but I would
prefer postgres. anyway html/css and a Rair templating engine are all
a given.

>> It is difficult to imagine how an application
>> (Dohickey) can be integrated into a website (the
>> database), and how submissions from Dohickey will
>> be transferred to the server. Have you tested this?
>> I have personally never done this, and I have only
>> worked with content management systems.
>> That's why I see myself as being more useful
>> in gathering data for the database, since I, at this
>> time at least, have a lot of time on my hands.

Nah I'll give you the outline structure:

/index
/client/* (as is)
/admin/index (you'll need to log on to see this)
/audit/submit (client talks to server)
/audit/review
/audit/merge
/hardware/view (NOT DONE)
/hardware/edit (NOT DONE)
/hardware/rate (NOT DONE)
/hardware/list (SEARCH RESULTS ETC, NOT DONE)
/hardware/browse (Browse classes as clever searches)

>> Another fear is that the website will not be
>> intuitive as well as pleasant to use, and hopefully
>> this can be worked out. It is especially important
>> to focus on ease of use for those who are
>> submitting ratings, and the behind the scenes work for
>> those who want to help out with the Dohickey website.

With help from many eyes the site will be molded around the best
feedback and help with html will help in that regard. it's not
important to me while the code is not written because I can't see it
even if I wanted to; I tend to make small plain templates that work
and then build up from there. but having templates from the start will
speed things up greatly.

>> Also, do you have any time tables in mind for when
>> something concrete can be constructed, and possibly
>> a finishing time? My idea is the sooner, the better.

Yes, December 2007 for full release, August 2007 for Beta of server. I
want to give myself lots of time because it's turning out to be hard
work.

>> I'll go ahead and sign up for the mailing list.

Thanks, you should receive this then.

Best Regards, Martin Owens

[Dohickey-public] Update on progress

[Martin O. <doc...@gm...>]

Hello followers,

In the next few days I'll be making the new 0.6 alpha release of the
dohickey client and hopefully will be able to begin the long awaited
server side improvements.

http://dohickey-project.com/client/screenshots.shtml

As you can see from the updated preview screenshot things are looking
good right now and the code looks much better, it's just gone through
a few weeks of me pulling bits out and making and remaking various
modules in the Hardware and HardwareTypes vain this allowed me to
Open/Save hardware profiles as well as provide a bunch of CLI scripts
for testing data and the backend code.

We're going to be using some interesting event callback features to
tell the client when it's updated a profile or hardware type
information or when information needs to be sent to the server. this
has already reduced code between the types and hardware items and
allowed each of the item that were the same to be updated at the same
time.

In this release the client will have a button to send information to
the server instead of trying to send the information without the users
knollege. we'll also be asking for the users hardware profile that we
can use for testing and various statistical and correctional work.

We won't be including monitor support since this will need a reworking
of ddccontrol and ddcprobe into a working program that can give us
monitor id's at the moment it's too unpredictable.

Also making the chop will be Ram and Processors which at the moment
don't have stable id's, future research though should allow us to
choose the variables needed to include these hardware items, it's just
not as important as getting a release out.

Upgrade information: since we have access to all the information about
the hardware a future roadmap item will be data that allows a user to
see what pieces of hardware can be upgraded and in which ways. we also
have access to empty slot information (cpu, ram, pci) that we can take
advantage of.

Best Regards, Martin Owens (DoctorMO)

Re: [Dohickey-public] Dohickey Alpha 0.5

[Martin O. <doc...@gm...>]

If you need any help with the python or the structure let me know,

I've recently just re-jiged and published the website to a new hosting server:

http://www.dohickey-project.com/

and you can find the wiki, not much in it at the moment but
'comming-soon' as they say.

http://dohickey.wikispaces.com/

It's still in alpha stage so it's at it's most changeable; I'm
thinking of making a Makefile too which would at least allow
uninstallation too but I have to think about how to do that.

Any help greatly appreciated.

Best Regards, Martin Owens

On 12/03/07, James Kramer <kra...@gm...> wrote:
> > Martin,
> > It works well.  Neat!  Very useful.  All my equipment had a five star
> > rating so I wasn't able to assess how the rating system was working.
> > You might want to rename the installation instructions README instead
> > of install but this is really minor and I am speaking from a Debian
> > viewpoint
> >
>
> Also, for installation, I used
> sudo python setup.py install
> which only makes sense by it may help others to install
>
> I have to check out the code I am not familiar with python but should
> be able to figure it out.
> jay
>

Re: [Dohickey-public] Dohickey Alpha 0.5

[James K. <kra...@gm...>]

> Martin,
> It works well.  Neat!  Very useful.  All my equipment had a five star
> rating so I wasn't able to assess how the rating system was working.
> You might want to rename the installation instructions README instead
> of install but this is really minor and I am speaking from a Debian
> viewpoint
>

Also, for installation, I used
sudo python setup.py install
which only makes sense by it may help others to install

I have to check out the code I am not familiar with python but should
be able to figure it out.
jay

Re: [Dohickey-public] Dohickey Alpha 0.5

[James K. <kra...@gm...>]

On 3/11/07, Martin Owens <doc...@gm...> wrote:
> OK perhaps sourceforge was down here are all the links:
>
> SF: https://sourceforge.net/projects/dohickey/
> Downloads: https://sourceforge.net/project/showfiles.php?group_id=177020
> Wiki: http://dohickey.wikispaces.com/
>
> do let me know if your still having problems, I recommend getting the
> 0.5.1 release.

Martin,
It works well.  Neat!  Very useful.  All my equipment had a five star
rating so I wasn't able to assess how the rating system was working.
You might want to rename the installation instructions README instead
of install but this is really minor and I am speaking from a Debian
viewpoint

[Dohickey-public] New Website

[Martin O. <doc...@gm...>]

Hi all,

In order to push forward the server side testing I've set up a
dreamhost account with a new domain name at
http://www.dohickey-project.com/ check it out; I've managed to
redesign some parts of the website to be cleaner and reduced the size
and bulk of it.

News etc has been updated; let me know if you spot any errors.

Best Regards, Martin Owens (Developer)

Re: [Dohickey-public] Dohickey Alpha 0.5

[Martin O. <doc...@gm...>]

OK perhaps sourceforge was down here are all the links:

SF: https://sourceforge.net/projects/dohickey/
Downloads: https://sourceforge.net/project/showfiles.php?group_id=177020
Wiki: http://dohickey.wikispaces.com/

do let me know if your still having problems, I recommend getting the
0.5.1 release.

Best Regards, Martin Owens

On 11/03/07, James Kramer <kra...@gm...> wrote:
> I was not able to connect to the link that you provided
> Jay
>
>
> On 3/4/07, Martin Owens <doc...@gm...> wrote:
> >
> > Hello All,
> >
> > I'm struggling a bit making sure the client for the Dohickey project
> > works on machines other than Ubuntu Edgy and also I've had people
> > asking me about updates and so forth so today I release a client alpha
> > which can be downloaded at sourceforge:
> >
> https://sourceforge.net/project/showfiles.php?group_id=177020
> >
> > I invite you all to download it and cause it problems and let me know
> > via bug tracker.
> >
> > The server portion (where votes are collected and hardware information
> > collect / distributed) is turned off (commented out of
> > /etc/dohickey.conf) as you can see it points to localhost as I haven't
> > a solid server with perl/apache/xapian if anyone has a bit of spare
> > space to run alpha tests on it would so very much help the testing and
> > fixing of problems.
> >
> > Thanks for your time.
> >
> > Best Regards, Martin Owens
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> > _______________________________________________
> > Discuss mailing list
> > Di...@bl...
> > http://lists.blu.org/mailman/listinfo/discuss
> >
>
>

[Dohickey-public] Dohickey Alpha 0.5

[Martin O. <doc...@gm...>]

Hi all,

The New Alpha Release is out and available via sourceofrge downloads page.

Grab a copy and give it a test, I need all the bug stomping I can get.

thanks all,

Best Regards, Martin Owens

[Dohickey-public] Server Side update

[Martin O. <doc...@gm...>]

The Hardware merging tool is now complete and I'm well on the way to
updating my object code. got a little side tracked with the users
stuff but I believe it'll be worth it in the end.

[Dohickey-public] Type Requests

[Martin O. <doc...@gm...>]

I've compleated the type merging tool on the server side, this was a
major bit of development and not at all simple.

The next steps:

 a) Hardware information merging tool (should be simpler than types)
 b) User Management Integration
 c) Search functionality with Xapian

[Dohickey-public] Review

[Martin O. <doc...@gm...>]

just in case, you should know that there are a lot of projects similar
to yours (that is, linux hardware databases)

what is below is a (very quick) usability study - when i ask you a
question, that means you should look into answering it somehow in
whatever place (website, application, etc.) is appropriate. that is,
*I* am not asking you these questions personally, but as a "random
user"

First impressions of website (before downloading application)

    * okay, i realize that this is some hardware database, but what
kind? all hardware? linux, windows, mac?
    * whats the point of this site? just to show you what hardware is out?
    * is this some kind of linux hardware compatibility list?
    * is this a search engine? looks very google-like. this is both
good and bad: the good is that it's nice, clean, easy to use, and fast
loading and to the point - the bad is that it makes me think its a www
search engine for hardware, but i bet its not
    * whats the point of a client? why is there a client link if it
has a search engine interface on the web? think about it: does google,
yahooo, etc. have a seperate google search client? i am sure that the
client is nice and useful, but i dont understand *why*
    * 'the dream' should probably be 'about'
    * 'administration' should definetly be hidden
    * as you can see, almost everything above has to do with one
thing: i have no idea what this is supposed to be exactly (and the
thing is, i seriously don't know what dohickey is supposed to be)

client install observations:

    * after clicking 'client' link, i still have no idea what the
client is all about "news" does not help me in this regard nor the
overall project stats
    * after reading 'about client' i now understand and think i
understand what the website is all about - took a lot of effort!
    * your system requirements page seems to be wrong, it should be
'python-gtk2' instead of 'gtk-python'
    * python-dbus requirement missing in list

client observations:

    * i really hope that the client is not sending any information to
anyone without approval.... this leads me to
    * need a send info button
    * tooltips! i have no idea what those buttons do (seriously). i
had to click and find out (and hope i dont break something)
    * the main window needs a title of some sorts.... what is that inside there?
    * because your two buttons are tall, you have a lot of space left
over... use it (see title suggestion above)
    * when i hit edit (why am i editing?), i have three buttons that i
have no idea what they do...ok, the plus sign one can be figured out,
but the rest? and the 'i' button does not do anything that i can tell
    * again, more information on what this edit screen is... title!
plus something like "please enter information that describes your
hardware"
    * and whats the purpose of the icons and images selection?
    * edit window is too small... i need to scroll, not good since the
window is so tiny and fitting everything inside would not make it much
bigger
    * i would suggest a different method of field design: instead of
<field name>: <field> try to use <field name>\n<field>
    * name field should be longer: it never fits the whole name string
    * name field usually gives bizare name which i doubt you want...
the first entry on my computer is: "RL5c476 II, RL5c476 II, R5C552
IEEE 1394 Controller(pci:1180:0476:0476:0552)"... i somehow doubt you
would want that in the db for a name... or maybe you do, i have no
idea what you want in that field.. name of product as on the box? if
so, do not prefill that information because you will get what i posted
above with most hardware
    * if you are not going to prefill, have a "product code" field
name with the text of whatever is previous so i don't make a mistake
and prefill information for the wrong hardware. this text should never
be editable - its just a copy of the text in the main window so i
remember what im filling in
    * revert, cancel, save buttons - i like that
    * dropdown type is a very good idea
    * two window design is nice! less the better...
    * maybe make the main window a little larger to start with
    * also, not really sure what you are trying to accomplish with
this program... why are users supposed to use it?
    * as i mentioned above, there are a lot of projects similar to
yours - what is the difference between what you are doing and everyone
else? it does not seem to be a linux compatibility database, so what
is it and why should i care?

also, as an aside, you may consider using existing data!