PDA

View Full Version : New website: LWPluginDB.com



DuneBoy
12-16-2007, 05:26 AM
It took longer than I would've liked, but I'm finally ready to announce the creation of my latest site the LightWave Plugin Database, www.LWPluginDB.com

It features an RSS feed for new and updated plugin entries, along with a "Today's Plugin" showcase entry. As well as feeds for search results.

Although it's not a wiki. It does let users add entries to the database, and edit the entries that they've made.

So now in addition to flay and google, we have another way to find those much needed plugins.

P.S. I was working on the entries for Fujio Ichikawa when his site went down. I had all the plugins saved, so until he comes back up I'm hosting all those FI's plugins on my site.

-EsHrA-
12-16-2007, 06:08 AM
excellent.


cheers,

mlon

Sensei
12-16-2007, 06:20 AM
EasySplit, EasySpline, VirtualRender, EasyMesh, SwiftEdgeLoop, SurfacePicker, TrueFillet have also Win64 bit versions..

Hopper
12-16-2007, 06:05 PM
Hi DuneBoy, I wrote a convenience plugin for creating new projects in Modeler, although I don't think it was too terribly popular. A handful of people thought it was useful, so others may also. However, I have no place to keep it. Will you have a local repository for any plugins?

DuneBoy
12-17-2007, 12:51 AM
...Will you have a local repository for any plugins?

Yes...eventually. Allowing authors to upload and host their plugins was in the list of things to do since the beginning, but it had to be put on hold to get the rest of the site done. Now that it is done I can investigate a logical, non-hacky, way of doing it.

I say non-hacky because the Files.aspx file that I'm using to display the links for FI's plugins was a quick hack that I'm not happy with.

I went ahead and added your plugin to the DB and am hosting the file. Nice plugin by the way. I did something similar a while back called Project Directory Maker, but it didn't use tabs or make as many directories.

kopperdrake
12-17-2007, 03:13 AM
thanks for this duneboy - nice idea for an rss feed :thumbsup:

riki
12-17-2007, 04:01 AM
Nice work, looks good.

DuneBoy
12-17-2007, 04:53 AM
Thanks.

The Files.aspx hack is gone. I just spent the last couple hours reworking the entry control so that a list of files can be shown on the entry page in place of a URL.

That was the first hurdle to letting authors upload their plugins. Today, after I get some sleep, I'll work on the add and edit plugin pages.

JVitale
12-18-2007, 01:00 AM
Wow!...you finally finished it...Congratulations Ken!!!

stib
12-18-2007, 06:09 AM
Nice idea, but without a way of sorting through them it's not nearly as useful as it could be.

It would be good if you could filter the plugins: free/non free, Modeler/layout etc. if not the ability to filter them, then how about some icons denoting the type of plugin it is and whether it's free or commercial, mac or PC etc.

It would also be good if they were in some sort of order.

Also a way of choosing how many per page would be good.

That said I've added the RSS feed and I'll keep an eye on it. Lightwave is nothing without the plugins and this is a great tool.

Hey how about someone writes a plugin that can search your database from within LW? So when you're modelling away and realise you need a polymorphous decombobulator plugin (and we all need one of those) you can just type it into a search field right there..

DuneBoy
12-18-2007, 06:10 AM
Wow!...you finally finished it...Congratulations Ken!!!

Thanks, I had to put my room remodel project on hold for a couple days. But as a result, authors can now upload files in place of posting a link.

Up to four files can be uploaded with a total size limit of 2 MB. For security reasons only .zip files are supported at the moment.

There's just a slight interface change I want to make then I can get back to adding entries, and remodeling my room.

stib
12-18-2007, 06:12 AM
I just realised that the info is there if you hover. That's a bit annoying IMHO, it's kinda like mystery meat navigation (http://www.webpagesthatsuck.com/mysterymeatnavigation.html). The functionality would be improved by having that info visible without having to hover your way down the list.

DuneBoy
12-18-2007, 07:33 AM
I just realised that the info is there if you hover. That's a bit annoying IMHO, it's kinda like mystery meat navigation (http://www.webpagesthatsuck.com/mysterymeatnavigation.html). The functionality would be improved by having that info visible without having to hover your way down the list.

The popup was implemented as a way of providing that data without inflating the file size since the popup gets its data from a separate XML file on demand. It also prevents cluttering the list both with lots of text and unused white space in the entries that have less data. I'll admit the popup isn't intuitive and while it does do what I intended I'll add "investigate a verbose list option" to my list of things to do. I like the icon idea, perhaps a row of little icons below the summary text.

Here's the reply to your other post:
The Advanced Search can filter the list (although with a 100 item limit).

I've actually had a lot of back and forth debate with myself about having the Availability value (i.e. free, commercial) as something to filter by. That currently isn't supported, my thinking is that if someone is trying to find a solution to a problem, letting them filter out any non-free plugins may keep them from finding that solution.

The lists are sorted, by default it is by the added/updated date descending. So new entries, or plugins which have been updated, are at the top. The lists can be resorted by clicking the Name or Date header text.

I actually planned for the ability to control the number of items per page, I just haven't added a user control which adjusts the value. Would a drop-down list with the options 10, 25, 50, 100 work?

I've thought of the different things that could be done client side with this site, a search plugin, as you suggested is a good idea. Another possibility would be a plugin or program that would notify the user when one of the plugins they have installed has been updated.

art
12-18-2007, 07:40 AM
It would be nice if keywords could be attached to each plugin, either by you or the site users. This would be useful for searching. I like the fact that we are allowed so search by particular plugin author.

DuneBoy
12-18-2007, 08:01 AM
It would be nice if keywords could be attached to each plugin, either by you or the site users. This would be useful for searching. I like the fact that we are allowed so search by particular plugin author.

A keyword field is another thing I've had a personal debate about. Because it could help the search engine locate plugins. But the reason I haven't (yet) implemented it is because there is the details field which would hopefully contain enough text that any key words would get used.

Once I get a large enough group of entries, I'll do some tests then any needed tweaks to improve search results.

A tag system would be interesting, perhaps that's what you ment.

art
12-18-2007, 09:23 AM
No, I did not mean keywords for the purpose of search engines. I guess I meant a tag system. Something like kvraudio.com does for their audio plugins.


A keyword field is another thing I've had a personal debate about. Because it could help the search engine locate plugins. But the reason I haven't (yet) implemented it is because there is the details field which would hopefully contain enough text that any key words would get used.

Once I get a large enough group of entries, I'll do some tests then any needed tweaks to improve search results.

A tag system would be interesting, perhaps that's what you ment.

stib
12-18-2007, 04:04 PM
Brilliant! Yes! An automatic update function would be brilliant! Like most LW users I have scads of plugins from all over the place and I have no idea whether any of my plugins have newer versions or not, or even where half of them came from. Having an automatic update function tied to your site would benefit both the users and the plugin writers. Do you have an API so I can start writing my plugin yet? :D

With the list sorting, maybe a little arrow widget on the column heading would indicate that the list was being sorted by that heading. I see the links now, but it didn't visually tell me that the links were for sorting the list.

I didn't think to do an advanced search when I wanted to filter the list. Perhaps you should call the link "filter and advanced search" or something. I'd actually put the basic filter checkboxes (OS, host and LW version) on the main list page, there's enough room at the top. If you clicked the advanced link it could then reveal the further checkboxes.

A dropdown would be the go for choosing how many results per page. And is there a reason for the 100 result limit from filtered searches? The searches from a filtered result should appear like the normal list view, with x results per page and the ability to go to the next page. Having the filter checkboxes at the top of the list would make this a quite intuitive way of browsing the list.

Aren't I a typical lightwaver: as soon as you release something I'm whining for more features. Good luck with it, it's a great resource.

Oh and you should get rid of the basic "find a plugin" search box when you go to the advanced search page.

DuneBoy
12-18-2007, 05:55 PM
An API shouldn't be too hard. The way I imagine it working there would be two modes, active and passive.
Active mode is used when the user presses a "Check for updates" button. In active mode the plugin requests the list of all updated plugins and compares it to what is installed (based on filenames listed in the LWEXTx.cfg), then alerts the user to any updates displaying the Plugin's name and a link.
Passive mode is when the plugin gets run at load time (it should have the option to adjust how frequent it actually checks for updates). In passive mode the plugin would give a start date (the date of the last check) and would be given a list of the plugins that have been updated since then.

At least that's the way I would do it.

I'll have to figure out a way to stick a sort indicator in the list header, appending text to the cell when the data gets bound removed the link. So it may take some research.

Here's the reason for there being a list and a separate search page, not that I like it. The data you see on a plugin entry page comes from 5+ different tables (for the non-DB people imagine a table like a spread sheet), Most of the data comes from the main table, but items like version, class, etc., are stored in two tables per item, one table is just a list of the options with a key like:
1 Win32
2 Win64
Then the second table links the main table to that table. It's like that for the OS, Host, Version and Class. My brother in-law helped me design the database (on a napkin), his name is Adnan Masood (http://axisebusiness.com/adnano/) so he deserves some of the thanks and blame.

Blame because to do a simple search for a 9.2, Win32, Layout Camera plugin you get a DB query that looks like this:


SELECT DISTINCT TOP 100 LWP_Main.StringID, LWP_Main.Name, LWP_Main.Summary, LWP_Main.DateUpdated FROM LWP_Main, LWP_OSLink, LWP_HostLink, LWP_VerLink, LWP_ClassLink
WHERE LWP_Main.GUID = LWP_OSLink.PluginGUID
AND LWP_Main.GUID = LWP_HostLink.PluginGUID
AND LWP_Main.GUID = LWP_VerLink.PluginGUID
AND LWP_Main.GUID = LWP_ClassLink.PluginGUID
AND LWP_OSLink.OSKey IN (1) AND LWP_HostLink.HostKey IN (1)
AND LWP_VerLink.VersionKey IN (9) AND LWP_ClassLink.ClassKey IN (2)
ORDER BY LWP_Main.DateUpdated DESC


The TOP 100 is where the limit gets set, that whole query is custom generated based on what options are checked. Adding Win64 to the search would make it "OSKey IN (1, 2)", and so on.

Now here is the problem. Paging. That query has no paging, thus the 100 limit. Whereas the List page never tests those other tables, it just uses 1 of 4 static queries to retrieve one page of data. Four queries are needed to account for the four different ways the list can be sorted.

That's the overly long and technical reason for there being no paging on the search page and the reason for the list page.

That said, now that I've got 5 well working queries I'll look into how to bring paging to the search results and thus unify the two pages.

On the upside, as you suggested, the Find a Plugin form no longer shows up on the search page.

stib
12-18-2007, 08:20 PM
ooh that database stuff just makes my stomach hurt. Well done your brother for being way too clever.

DuneBoy
12-20-2007, 01:11 AM
Okay, the list page is gone. There is now a combined list / search page. The paging controls below the list have also been changed, and an items per page drop down has been added.

The column header now has an arrow to show the direction of sorting. Refreshing the page may be needed so that you get the updated .css file, otherwise the arrows won't show.

I had to give up some efficiency so that the search results could page. Instead of doing the pagination in the DB query (like the old list did), I now pull all the results and let the datagrid control handle the pagination.

I didn't get as much time to test the new code as I would've liked, but it seems to work fine.

Next on the list is research into a replacement for the detail popup on the list.

Red_Oddity
12-21-2007, 03:24 AM
Have you tried using (INNER) JOINS in your search or subqueries? It is possible to use multiple tables in the same query command.

Red_Oddity
12-21-2007, 04:02 AM
Ignore my silly post above...stupid 5 minute edit rule...seems you fixed it since last time i cjecked your site.

My only gripe is, that the layout feels messy, not sure what the word is, but think toys for toddlers (and i don't mean this in a kick in the face kind of remark), everything seems to be too big.
Also, the location of the search in relation to the list is illogical (to my feel atleast).
Maybe use a search menu that just shows the search string input, and when you hover over it have it pop up the rest of the options below it.

Just thinking outloud, nice initiative though.

DuneBoy
12-21-2007, 05:19 AM
Since the list currently only needs data from the LWP_Main table, explicit JOINs aren't needed. Just the implicit JOIN from adding the tables to the FROM clause and using the IN tests.

Currently, attempting to get an entry along with let's say it's OS data produces:
Entry ABC - Win32
Entry ABC - Win64

That is, for each matching row in the Class table I get another copy of the LWP_Main data. So while the rows are in fact distinct, there is a large amount of redundant data. The old list page was the only page which used sub-queries, since it did the pagination in the query, but it looks like I may once again have to use them to get the extra data into the list (performance allowing).


My only gripe is, that the layout feels messy, not sure what the word is, but think toys for toddlers (and i don't mean this in a kick in the face kind of remark), everything seems to be too big.
Also, the location of the search in relation to the list is illogical (to my feel atleast).
Maybe use a search menu that just shows the search string input, and when you hover over it have it pop up the rest of the options below it.

Just thinking outloud, nice initiative though.

No offense taken. There's been a lot of issues/flaws brought up and I'm glad for it, since it can make the site better (like merging the list and search pages).

I'll admit that most of the text is a bit large, perhaps even too big. But as my brother-in-law likes to say "I'm a developer, not a designer." I designed it to be legible and to scale to different screens, so that people running at very high resolution don't end up with a small area of content and a bunch of background.

I'm not opposed to design changes, and will probably make some, but at the moment the high priority work is in the code-behinds and getting entries made. When that's done, I can rethink the presentation layer. Including the search options display.